가장 흔한 보안 오류는 “Admin 줘버려, 끝”

Source: Dev.to

우리가 압박을 받을 때, 거의 항상 가장 빠른 해결책이 승리합니다. 뭔가가 실패하고, 누군가 접근이 필요하고, 배포가 코앞에 있습니다. 그래서 우리는 흔히 하는 일을 합니다: “지금은” 권한을 넓게 부여합니다.
문제는 일시적인 것이 영원히 남아버린다는 점입니다.

최소 권한 원칙은 편집증이 아니라 의도입니다. 오류가 발생해도 영향이 작게 만들고, 보안을 보다 예측 가능하게 하기 위해 필요한 것만 부여합니다.

최소 권한이란 실제로 무엇을 의미하는가

최소 권한은 다음을 의미합니다:

• 필요한 작업만
• 필요한 리소스만
• 필요할 때만
• 올바른 정체성에만

좋은 정책은 다음을 답합니다:

• 이 시스템이 무엇을 해야 하는가
• 어떤 리소스에서 수행할 것인가
• 절대로 할 수 없어야 할 일은 무엇인가

IAM은 보안만을 위한 것이 아닙니다. IAM은 안정성에도 기여합니다. 권한이 과도한 역할은 더 많은 것을 더 빨리 깨뜨릴 수 있습니다.

왜 대규모에서 중요한가

작은 환경에서는 넓은 권한이 바로 악용되지 않을 수도 있습니다. 하지만 큰 환경에서는 언젠가 반드시 문제가 됩니다.

최소 권한은 다음으로부터 보호합니다:

• 자격 증명이 유출될 경우 발생하는 대규모 영향
• 프로덕션에서의 실수로 인한 삭제
• 아무도 기억하지 못하는 오래된 역할
• 설명하기 어려운 감사

또한 디버깅에 도움이 됩니다. 무언가가 실패하면 접근 제한이 실제로 적용됐는지 알 수 있습니다.

우리가 흔히 저지르는 실수

가장 흔한 패턴은 다음과 같습니다:

• *:* 같은 와일드카드
• 정리 없이 복사한 정책
• 모든 것을 담당하는 하나의 역할
• 절대 제거되지 않는 임시 권한
• 배포와 실행 권한을 분리하지 않음

이러한 실수는 좋은 팀에서도 발생합니다. 해결책은 명확한 패턴을 만드는 것입니다.

예시: 나쁜 정책 vs 좋은 정책

예시 1: S3 접근

❌ 나쁜 정책 (너무 광범위)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": "*"
    }
  ]
}

✅ 좋은 정책 (제한적이고 실용적)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListBucketInPrefix",
      "Effect": "Allow",
      "Action": ["s3:ListBucket"],
      "Resource": "arn:aws:s3:::my-app-data",
      "Condition": {
        "StringLike": {
          "s3:prefix": ["public/*"]
        }
      }
    },
    {
      "Sid": "ReadObjectsInPrefix",
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::my-app-data/public/*"
    }
  ]
}

IAM을 올바르게 설계하기 위한 간단한 시스템

• 역할을 분리한다
• 최소한으로 시작하고 필요할 때 확장한다
• SCP와 경계(boundaries) 같은 가드레일을 사용한다
• 권한을 정기적으로 검토하고 정리한다

미니 프로젝트: Terraform을 사용한 Lambda + S3 최소 권한 역할

목표

다음 리소스를 만든다:

• S3 버킷
• Lambda 실행 역할
• 최소 권한 정책
• 역할에 정책을 연결한다

Lambda는 다음을 수행할 수 있다:

• public/ 에서만 읽기
• results/ 에만 쓰기
• CloudWatch에 로그 쓰기