구축하지 않은 클라우드 환경 보안하기

클라우드 계정의 열쇠를 받았는데, 그곳은 3년간 관리되지 않은 채 자라나고 있다. 문서는 없고, IAM에는 와일드카드 권한을 가진 40개 역할이 있으며, 누군가 생성한 S3 버킷들은 기억 속에만 남아 있고, 네트워크 토폴로지를 이해한 마지막 사람은 2022년에 회사를 떠났다. 이것은 대부분의 채용공고가 인정하는 것보다 훨씬 흔하며, 처음 한 달이 그 이후 모든 것의 기조를 결정한다.

뭔가 건드리기 전에 인벤토리를 만들어라

즉시 보안을 강화하려는 충동을 참아라. 먼저 지도가 필요하다. aws resourcegroupstaggingapi get-resources를 모든 리전에 걸쳐 실행해라. us-east-1뿐 아니라, ap-southeast-2에도 필요하다. 팀들은 테스트 리소스를 돌려놓고 잊는 것을 좋아한다. 그것을 AWS Config와 짝지어라. 이미 활성화되어 있으면 그것을 사용하고, 아니면 지금 켜라. Azure에서는 az resource list --output table을 스프레드시트로 파이프하면 초기 점검으로 충분하다. GCP에서는 Cloud Asset Inventory의 gcloud asset search-all-resources가 같은 뷰를 제공한다.

청구 내역과 대조해라. 비용이 들고 있는 것은 모두 리소스 인벤토리에 나타나야 하고, 최근 활동이 없는 인벤토리의 항목은 아카이빙 후보다. 여기서의 불일치는 보통 무서운 것들이 숨어 있는 곳이다. 공개 IP를 가진 고아 EC2 인스턴스, 암호화되지 않은 채 남겨진 잊혀진 RDS 스냅샷, 아무것도 가리키지 않는 로드 밸런서.

IAM을 범죄 현장처럼 감사하라

IAM 정책 하나하나를 가져와서 "Action": "*" 다음에 "Resource": "*"를 찾아라. 이 조합은 소수의 비상 관리자 역할 외에는 존재해서는 안 되며, 그것도 MFA 강제 및 CloudTrail 경고가 붙어 있어야 한다. IAM Access Analyzer를 사용해서 외부 계정에 대한 접근을 부여하는 역할을 찾아라. 이것은 의도적인 교차 계정 신뢰 관계와 Terraform 모듈을 잘못된 계정 ID에 대해 테스트한 실수를 모두 걸러낸다.

aws iam generate-credential-report로 90일 이상 된 접근 키를 확인해라. 상속받은 환경은 거의 항상 서비스 계정에 붙어 있는 장수명 키를 가지고 있으며, 때로는 Lambda 환경 변수나 Jenkins 작업에 하드코딩되어 있다. 그것들을 회전시켜라. 하지만 단계적으로 해라. 야간 배치 작업이 의존하는 키를 새벽 2시에 죽이는 것은 첫 주에 호출받는 방법이다.

공격자가 발견하기 전에 공개 노출을 찾아라

VPC를 통해 네트워크 도달 가능성 검사를 실행해라. 80/443 이외의 보안 그룹에 0.0.0.0/0이 있으면 가정이 아니라 정당화가 필요하다. ScoutSuite나 Prowler 같은 도구는 계정을 몇 분 만에 처리하고 심각도별로 순위가 매겨진 보고서를 뱉어낸다. 처음부터 자신의 체크리스트를 만드는 대신 그곳에서 시작해라.

S3 버킷은 상속받은 환경의 전형적인 지뢰이므로 특별한 주의가 필요하다. 버킷 정책과 계정 수준 Block Public Access 설정을 모두 확인해라. 누군가는 몇 년 전 일회성 정적 사이트를 위해 계정 기본값을 비활성화했을 수도 있고 다시 켜지 않았을 수도 있다. aws s3api list-buckets을 각각에 대해 get-bucket-acl과 get-bucket-policy-status를 확인하는 루프와 결합하면, 대부분 계정에서 10분 이내에 깔끔한 그림을 얻는다.

신뢰를 설정하기 전에 로깅을 설정해라

CloudTrail, VPC Flow Logs, 또는 GuardDuty가 이미 모든 곳에서 실행 중이지 않으면, 다른 변경을 하기 전에 지금 켜라. 이 시점 이후에 무슨 일이 일어나는지 기록해야 하고, 뭔가를 삭제하기 전에 그 기록을 원한다. 삭제는 실수가 일어나고 새로운 사람의 탓으로 돌려지는 바로 그때이기 때문이다. 가능하면 별도 계정이나 구독으로 로그를 전송해라. 그래야 손상된 워크로드도 자신의 증거를 지울 수 없다.

GuardDuty나 Azure Defender for Cloud를 설정하고 경고를 실제로 누군가 확인하는 곳으로 라우팅해라. 읽지 않은 메시지 400개인 Slack 채널은 안 된다. 탐지 도구의 가치는 경고가 공허한 곳에 떨어지면 거의 0에 가깝다.

가장 시끄러운 문제부터 고치고, 모든 것을 문서화해라

상속받은 환경을 한 스프린트에 고칠 수 없다. 영향 범위로 우선순위를 정해라. 공개 데이터 노출 먼저, 그 다음 과도한 권한의 신원, 그 다음 네트워크 분할, 그 다음 모든 것. 당신이 발견한 것과 변경한 것을 기록해라. 평문 Google Doc이라도 괜찮다. 당신에게서 이것을 상속받을 다음 사람이 당신이 받은 것보다 나은 것을 받을 자격이 있기 때문이다.

보안 그룹을 강화했을 때 개발자의 통합 테스트가 실패하기 시작하면 반발을 예상해라. 그것은 정상이다. 감사가 작동 중이라는 뜻이다. 운영 환경의 뭔가를 바꾸기 전에 워크로드를 소유하는 팀과 대화해라. 그리고 처음 두 주간을 위해 롤백 계획을 준비해두어라.

클라우드 감사 뒤의 도구와 추론에 대해 더 알아보려면, Korra Studio의 IAM 강화 및 클라우드 탐지 엔지니어링 세션을 확인해라. 둘 다 위의 워크플로우와 잘 어울린다.