기록들 https://github.com/ndgndg91

Replay Attack 이란? replay attack 은 공격자가 유효한 네트워크 데이터 패킷을 가로채서 이후에 다시 사용하는 네트워크 공격의 유형이다. 데이터를 다시 전송하여 시스템이 정상적인 데이터로 처리하도록 한다. replay attack 은 실제로 정상적인 요청으로 보이기 때문에 탐지가 어렵다. 덧붙여 원래 전송이 암호환된 경우에도 성공할 수 있다. replay attack 은 반복적인 요청을 통해 시스템에 과부하를 줄 수 있다. 이로 인해 시스템의 정상적인 작동을 방해할 수 있다. 공격자는 그림과 같이 데이터 전송이 시작될 때까지 기다린다. 이후에 통신 채널을 스니핑하여 데이터를 추출한다. 공격자는 데이터를 입수하여 목적에 따라 데이터를 수정해서 다시 사용할 수도 있다. 수신자는 변조된 데이터를 받았지만 정상적인 데이터로 취급한다. 대표적인 4가지 유형이 있다. 네트워크, 무선, 세션, HTTP 가 있다. 네트워크 replay attack 은 공격자가 네트워크 트래픽을 가로챈 후 나중에 다시 전송한다. Wireshark 또는 tcpdump 와 같은 도구를 사용한다. 무선 replay attack 도 동일하게 무선 통신을 가로챈 다음 다시 전송한다. 세션 replay attack 은 두 당사자 간의 세션을 가로챕니다. HTTP replay attack 은 공격자가 HTTP 요청과 응답을 캡처하여 HTTP replay attack을 실행한다. 실제 예시 앨리스가 웹을 사용하여 온라인 뱅킹 계좌에 로그인하려고 한다고 가정한다. 앨리스가 로그인 자격 증명을 입력하고 제출 버튼을 클릭하면 로그인 요청이 인터넷을 통해 은행 서버로 전송된다. 공격자 밥은 네트워크를 모니터링하여 로그인 요청이 전송되는 것을 캡처한다. 그런 다음 밥은 앨리스가 계정에서 로그아웃할 때까지 기다렸다가 캡처한 로그인 요청을 은행 서버로 재전송한다. 로그인 요청이 유효하므로 서버는 이를 수락하고 밥에게 앨리스의 계정에 대한 액세스 권한을 부여한다. 어떻게 하면 Replay Attack...

 GitOps 를 구현하는 과정에서 고민했었던 부분 그리고 해결한 방법을 정리하려고 한다. GitOps 에서 크게 Application Repository ( Code Repository ) 와 Environment Repository ( State Repository ) 두 가지의 Repository 로 정의가 된다. 조직의 프로세스나 크기, 형태, 철학마다 다르겠지만, 일반적인 회사에서나 어떤 프로젝트에서 협업을 할 때 보통 개발팀과 운영팀이라는 개념으로 나뉠 수 있을 것이다. 이 때 보통 Application Repository 는 개발팀이 Environment Repository 는 운영팀이 관리할 것이다. 개발팀에서 지속적으로 새로운 기능 및 유지 보수를 진행함에 따라서 소프트웨어의 변경이 일어난다. 해당 변경은 CI 를 통해서 새로운 Container Image 를 생산할 것이다. 이 때 운영팀은 Image 들의 버전을 Environment Repository 에 반영해야 한다.  이 과정에서 여러가지 의문점이 들었다. 운영팀은 Environment Repository 의 Application 들의 버전 변경을 수동으로 반영할까 자동으로 반영할까? 수동으로 반영하는 프로세스라면 휴먼에러가 발생하지 않을까? 발생한다면 어떻게 대처할까? 자동으로 반영한다면 그것또한 무결함을 보장할 수 있을까? 이러한 의문점들은 귀결은 "Environment Repository 를 어떻게 관리하는게 좋을까?" 이다. 조금만 생각해보면 해당 질문에 정답이 있는것은 아니라는 결론이다. 모든것은 현재 해당 프로젝트 해당 조직이 처한 context 에 따라 다를것이다. 규모가 큰 조직일수록 관리해야할 application 이 많아서 수동으로 관리하는 것에 한계를 느낄 것이고, 반대로 규모가 작은 조직일수록 수가 적은 application 들을 관리하기 위해서 자동화를 하는 것에 더 비용을 크게 느낄수 도 있을 것이다.  개인적으로 자동화는 단기적인 관점...

 Mutable Infrastructure 필요할 때 변경하고 업그레이드하는 인프라를 말한다. 예를 들어 10 대의 VM 혹은 여러 대의 물리 서버가 있을 경우, 관리자는 SSH 접속을 통해 하나하나 접속하여 패키지를 수동으로 업그레이드 하거나 다운그레이드 하면서 직접 관리한다. 그리고 기존 서버에 직접 새 코드를 배포한다. 이 과정에서 패키지 설치 혹은 변경에 실패할 수 도 있고 성공할 수 도있다. 이로 인해서 서버간의 조금씩 차이가 발생하게 된다. 제각기 다른 크기의 눈송이와 같다고 하여 snowflake server 라 부른다. 다른 용어로는 configuration drift 라고 한다. Immutable Infrastructure Mutable 과는 다르게, 한 번 프로비전되거나 배포가 되었을 때 해당 서버의 변경을 만들지 않는다. 변경사항이 발생하거나 업데이트가 필요할 때는 해당 서버에서 작업하지 않고, 새로운 VM 혹은 이미지를 통해서 서버를 생성하고 교체한다. 이전 버전의 서버는 버려진다. 재에서 부터 다시 살아나는 피닉스에 비유하여 Phoenix server 라 부른다. Pet (Snowflake Server) and Cattle (Phoenix Server) 눈송이 서버와 피닉스 서버 처럼 비유되는 또 다른 표현이 있다. 바로 pet 과 cattle 이다. 왜 snowflake server 를 pet 에 비유했을까? pet 은 애완동물이다. 애완동물은 하나하나 제각기 주인들에게 특별하게 여겨지며 사랑받는다. 강아지의 경우 이름은 "호두", "룽지", "희동이" 등 각각 특별하다. 이는 snowflake server 처럼 각각의 서버가 다르게 설정될 수 있다는 것에 비유해서 pet 이라는 별칭이 붙게 되었다. 그렇다면 phoenix server 는 어째서 cattle 에 비유될까? cattle 은 소, 가축을 의미한다. 보통 농장에서 가축을 키울 때, 애완동물과는 다르게 사육한다. 가축에게는...

유투브 GOTO Conferences 채널에서 마틴 파울러 형님과 샘 뉴먼 형님이 MSA 를 언제해야되고 언제 하면 안되는가? 대한 토론을 담은 영상을 보았다. https://www.youtube.com/watch?v=GBTdnfD6s5Q 개인적으로 MSA 에 대한 경험이 없는 나로서는 두 형님들의 토론이 상당히 흥미를 가지고 보았다. 영상의 시작은 샘 뉴먼 형님이 아래의 책 Monolith to Microservices 란 책을 왜 집필하게 되었는지에 대한 질문으로 시작한다. 샘 뉴먼 형님은 2014년에 아래의 Building Microservices 란 책을 집필했다. 그리고 Monolilth to Microservices 는 아래의 책의 second edition 이라고 한다. 그리고 Monolith to Microservices 에서는 어떻게 큰 모놀리틱을 작게 나눌지에 대한 내용을 주로 다루었다고 한다. 그리고 해당 내용을 집필하는 과정에서 보다 면밀한 내용을 다루고 싶었다고 한다. 대화내용 정리.. 그리고, 마틴 파울러 형님이 나오면서 묻는다.  고작 천 줄의 코드의 프로그램을 만들면서, MSA 를 옹호하고  MSA 를 사용하면서 100줄 코드로 구성된 여러 서비스로 나누는 것을 보았다. 하지만, MSA 에 대해서 부정적인 견해를 가진 사람들은 찾기 힘들다. 단지 새로운 기술을 사용하고 싶어서 채택한다.  진정으로 언제 MSA 사용해야 된다고 생각하는가? 이에 샘 뉴먼 형님은 이렇게 답한다. MSA 를 하면서 MSA 가 주는 장점이 무엇인지 의식해야 한다고 말하며 아래의 3가지를 말해준다. - More options to scale up applications. (스케일 업에 대한 보다 많은 선택지) - Independent deployability (독립적인 배포) - Limit the "blast radius" of failure (장애 확산 방지) 그리고 James Lewis 말을 인용한다. "Microservices...