조용한 개발 노트

보안은 점검 가능해야 한다보안이 잘 되어 있는지를 묻는 질문은 대부분 추상적으로 끝난다.우리는 보안을 중요하게 생각한다취약점은 최대한 막고 있다사고 대응 프로세스가 있다하지만 운영 가능한 Secure System은 이런 문장으로 평가되지 않는다.지금 이 순간, 우리는 무엇을 알고 무엇을 통제할 수 있는가이 글은 Secure 시리즈 전체를 점검 질문(Checklist) 형태로 정리한 최종 편이다.1. Identity 체크리스트모든 요청의 주체를 명확히 식별할 수 있는가사람, 서비스, 배치 작업의 Identity가 구분되어 있는가Identity의 수명은 제한되어 있는가사용하지 않는 Identity를 즉시 회수할 수 있는가Identity가 불분명하면, 이후 모든 보안 판단은 무력해진다.2. Authorizat..

보안은 결과가 아니라 과정이다많은 팀이 보안을 이렇게 정의한다.취약점이 없으면 안전하다하지만 실제 시스템에서 보안은 완성 상태로 존재하지 않는다.새 기능이 추가되고, 권한이 바뀌고, 운영 환경이 변하면서 보안 상태도 계속 변한다.그래서 Secure-by-Design은 보안 기능의 집합이 아니라 설계 과정 전반에 깔린 사고 방식이다.Secure-by-Design은 무엇을 바꾸는가Secure-by-Design은 “어떻게 막을 것인가”보다 “어떻게 설계할 것인가”를 먼저 묻는다.이 시스템은 누구를 신뢰하는가신뢰가 깨지면 어디까지 영향이 가는가침해를 전제로도 운영 가능한가이 질문이 빠진 보안은 언제나 사후 대응으로 끝난다.보안 기능 나열의 한계보안을 기능 목록으로 접근하면 다음 패턴이 반복된다.인증을 붙인다권한..

보안 사고는 조용히 시작된다많은 보안 사고는 이렇게 발견된다.데이터가 이미 유출된 뒤권한이 오랫동안 오남용된 뒤외부 제보가 들어온 뒤이는 보안 장치가 없어서가 아니라, 보안 상태를 관측하지 못했기 때문이다.보안에서 가장 중요한 질문보안에서 가장 중요한 질문은 이것이다.지금 무슨 일이 벌어지고 있는가차단 규칙이나 암호화는 이 질문에 답하지 못한다.Observability는 보안 사고를 인지 가능하게 만드는 전제다.왜 보안 사고는 감지되지 않는가보안 사고가 감지되지 않는 이유는 단순하다.정상 트래픽과 구분되지 않는다부분적으로만 발생한다오랜 시간에 걸쳐 누적된다즉, 보안 사고는 시스템 장애처럼 보이지 않는다.보안 관점의 Observability는 무엇이 다른가일반적인 Observability는 성능과 안정성에..

Kubernetes는 보안을 자동으로 해결해주지 않는다Kubernetes를 도입하면 보안이 좋아질 것처럼 느껴진다.인프라가 표준화된다권한 모델이 존재한다네트워크 정책을 적용할 수 있다하지만 Kubernetes는 보안을 제공하지 않는다.Kubernetes는 보안을 설계할 수 있는 도구를 제공할 뿐이다.Pod는 신뢰 단위가 아니다Kubernetes 환경에서 흔히 생기는 오해는 이것이다.같은 클러스터 안의 Pod는 신뢰할 수 있다하지만 Pod는 다음 특성을 가진다.언제든 재생성된다IP가 고정되지 않는다코드와 설정이 쉽게 바뀐다즉, Pod는 신뢰의 기준이 될 수 없는 존재다.ServiceAccount는 Identity다Kubernetes에서 ServiceAccount는 단순한 설정이 아니다.ServiceAcco..

내부 네트워크는 안전하다는 가정오랫동안 보안은 다음 전제를 기반으로 설계됐다.내부 네트워크는 신뢰할 수 있다이 전제 아래에서 보안은 경계에 집중됐다.외부 접근은 차단한다내부 접근은 허용한다방화벽과 VPN으로 경계를 만든다하지만 이 모델은 점점 현실과 어긋나고 있다.왜 Network Boundary가 무너졌는가내부 네트워크 신뢰 모델이 무너진 이유는 명확하다.클라우드 환경의 확산서비스와 인프라의 동적 변화자격 증명 기반 접근 증가네트워크 위치는 더 이상 신뢰의 기준이 될 수 없다.VPN은 신뢰를 확장할 뿐이다VPN은 내부 네트워크로의 접근을 제공한다.문제는 VPN이 다음을 전제로 한다는 점이다.연결된 사용자는 신뢰 가능하다연결 이후의 행위는 안전하다하지만 실제로는:탈취된 계정으로 접속 가능접속 후 과도한 ..

Secret은 숨긴다고 안전해지지 않는다보안 사고가 발생하면 흔히 이런 조치를 한다.코드에서 Secret을 제거한다환경 변수로 옮긴다설정 파일로 분리한다이 조치는 필요하지만 충분하지 않다.Secret의 위험성은 어디에 있느냐보다 어떻게 관리되느냐에 있다.Secret이란 무엇인가Secret은 단순한 문자열이 아니다.비밀번호API Key토큰 서명 키인증서 개인 키공통점은 하나다.이 값을 아는 순간, 권한이 생긴다즉, Secret은 권한 그 자체다.왜 Secret은 코드보다 위험한가코드는 유출되더라도 즉시 시스템을 장악하지는 못한다.하지만 Secret은 다르다.알게 되는 순간 즉시 사용 가능추가 검증 없이 권한 획득그래서 Secret 유출은 즉각적인 침해로 이어진다.환경 변수의 착시환경 변수는 Secret을 ..

가장 위험한 요청은 인증된 요청이다API 보안 사고를 떠올리면 흔히 이렇게 생각한다.인증을 우회했다토큰을 위조했다비밀번호를 탈취했다하지만 실제로 가장 빈번한 사고는 정상적으로 인증된 요청에서 발생한다.이 요청들은 겉보기에는 아무 문제가 없다.API는 무엇을 신뢰하는가많은 API는 다음과 같은 가정을 깔고 설계된다.인증을 통과했다정상 사용자다따라서 요청은 안전하다이 가정이 API Security의 출발점이자 가장 큰 취약점이다.인증은 요청의 의도를 보장하지 않는다.IDOR는 왜 반복해서 발생하는가IDOR(Insecure Direct Object Reference)는 가장 흔한 API 취약점이다.구조는 단순하다.요청자는 인증되어 있다리소스 식별자를 직접 전달한다서버는 소유권을 확인하지 않는다이때 공격자는 다..

보안 사고는 권한 문제로 귀결된다많은 보안 사고의 시작은 인증이 아니라 권한이다.정상적으로 로그인했다유효한 토큰을 사용했다하지만 하면 안 되는 일을 했다이 상황에서 시스템은 이미 한 가지를 잘못 가정했다.이 주체에게 이 권한을 줘도 괜찮다Authorization은 이 가정을 코드로 고정하는 작업이다.Authorization은 정적이지 않다Authorization은 한 번 설정하면 끝나는 규칙처럼 보이지만, 실제로는 지속적으로 변한다.기능이 추가된다조직 구조가 바뀐다업무 흐름이 달라진다권한은 늘어나고, 예외는 쌓인다.이 변화 속에서 Authorization은 설계 의도에서 점점 멀어진다.Role 기반 접근 제어의 구조적 한계Role 기반 접근 제어는 가장 널리 사용된다.관리자운영자일반 사용자초기에는 단순하..

보안 사고는 대부분 신원 확인 실패에서 시작된다많은 보안 사고는 이렇게 설명된다.인증이 뚫렸다토큰이 유출됐다권한이 잘못 설정됐다하지만 이 설명들은 모두 하나의 질문으로 수렴한다.시스템은 누구를 믿었는가Identity는 이 질문에 대한 시스템의 공식적인 답이다.Identity는 계정이 아니다Identity를 사용자 계정으로만 이해하면 보안 설계는 즉시 한계를 드러낸다.현대 시스템에서 Identity는 다음을 모두 포함한다.사람서비스프로세스자동화된 작업즉, Identity는 행위를 수행하는 주체 전체를 의미한다.Identity는 무엇을 증명하는가Identity의 핵심 역할은 단순하다.지금 이 요청의 주체가 누구인가이 질문에 답하지 못하면, 그 이후의 모든 보안 판단은 의미를 잃는다.권한 검사는 Identit..

보안은 언제 등장하는가많은 시스템에서 보안은 항상 같은 시점에 등장한다.기능 개발이 어느 정도 끝났을 때외부 공개를 앞두고문제가 실제로 발생한 이후이 시점에서의 보안은 대부분 추가 기능처럼 다뤄진다.인증을 붙이고, 접근을 막고, 로그를 남긴다. 하지만 이 방식은 구조적으로 한계를 가진다.보안을 기능으로 취급하면 생기는 문제보안을 기능으로 취급하면 시스템에는 암묵적인 전제가 깔린다.기본적으로는 안전하다일부 지점만 보호하면 된다문제가 생기면 나중에 막으면 된다이 전제는 대부분의 보안 사고에서 직접적인 원인이 된다.사고의 원인은 종종 취약한 암호가 아니라 잘못된 신뢰 가정이다.Secure의 출발점은 신뢰가 아니다Secure 시스템의 출발점은 무언가를 더 보호하는 것이 아니다.무엇을 신뢰하지 않을 것인가이 질문..