[AWS-Security] 4.2. IAM 모범 사례 수집

1. 모범 사례 시나리오

• IAM을 설정할 때 동일한 목표를 달성할 수 있는 방법은 여러 가지가 있다. 각 방법은 난이도와 보안 수준이 모두 다르다.
• 특정 단일 사용자에게 DynamoDB 테이블에서 쿼리하고 S3 버킷의 객체를 읽어야 하는 권한을 줘야 하는 상황을 가정한다.

1. 관리자 정책 (Administrator Policy) 연결 : 모든 것에 대한 접근 권한을 줘버리는 가장 쉬운 방법이지만, 가장 안전하지 않은 최악의 옵션이다.
2. 자체 맞춤 정책 작성 : 사용자에게 필요한 딱 그 권한만 직접 코딩해서 부여한다. 더 안전하지만 훨씬 더 많은 작업(시간, 노력)을 수행해야 한다.
3. AWS 관리형 정책 부여 (중간 옵션) : 적은 작업으로 적당한 수준의 보안을 제공하는 타협안이다.
   (DynamoDBReadOnlyAccess 및 S3ReadOnlyAccess라는 AWS 관리형 정책 부여)

1.1. IAM에서 접근 허용을 평가하는 다양한 방법

조직에서 권한을 부여할 때마다 위 3가지 옵션 중 하나를 선택해야 한다.

평가 기준	관리자 정책 (모든 권한 허용)	맞춤 정책 (직접 세밀하게 작성)	AWS 관리형 읽기 전용 정책 (AWS 제공 템플릿)
보안 이점	(-) 없음: 보안상 얻을 수 있는 이득이 전혀 없다.	(+) 최소 필수 권한 부여: 완벽하게 필요한 것만 허용한다.	(+) 수정 권한이 부여되지 않음: 읽기만 가능하므로 데이터를 지우거나 변조할 수 없다.
위협 모델과의 관계 (스푸핑 발생 시)	(-) 높은 위험: 해커가 계정을 탈취(스푸핑)하면 회사 전체 시스템이 장악된다.	(+) 위험을 크게 줄임: 해커가 계정을 탈취해도 해당 DynamoDB와 S3 외에는 건드릴 수 없다.	(+) 위험 감소 / (-) 불필요한 위험 존재: 계정이 털려도 시스템 파괴는 막을 수 있지만(+), 해당 정책이 허용하는 다른 불필요한 테이블의 데이터까지 유출될 위험(-)은 여전히 남아있다.
비용 (편의성 측면)	(+) 구현하기 쉬움 / (+) 차단 안 됨: 설정이 1초면 끝나고, 권한 부족(접근 거부) 에러가 날 일이 없어 개발이 막히지 않는다.	(-) 추가 작업 / (-) 관리할 리소스 증가 / (-) 실수할 기회: 정책을 짜고 관리하는 데 품이 많이 들고, 설정 실수로 장애가 날 수 있다.	(+) 구현하기 쉬움: AWS가 만들어둔 걸 클릭만 해서 연결하면 되므로 매우 편리하다.

1.2. 결론

이 질문에 제대로 답하려면 혼자 결정하는 것이 아니라 보안, 개발, 운영의 이해관계자로부터 피드백을 받아야 한다.
그래야 조직 전체의 비용과 이점을 가장 명확하게 파악할 수 있다.

• 가상의 예시에서의 결정
  • 이 예시의 조직은 고민 끝에 세 번째 옵션인 AWS 관리형 읽기 전용 정책’을 선택할 수 있다.
  • 왜냐하면 “추가 작업이 거의 발생하지 않으면서도(편의성 확보) 위험을 일부 줄여주기(보안 가치 확보)” 때문이다.
• 궁극적인 모범 사례의 의미
  • 다른 사용자에게 권한을 줄 때마다 매번 표를 그리고 회의를 할 수는 없다.
  • 대신, 이 과정을 한 번 거친 후에 “우리 조직은 앞으로 이런 단순 조회 작업에는 ‘AWS 관리형 읽기 전용 정책’을 우선적으로 사용한다”와 같은 ‘결정을 내리기 위한 규칙’을 만들어 낸다.

즉, IAM 모범 사례란 ‘어떤 특정 기술적 설정’을 의미하는 것이 아니라, ‘IAM 리소스를 구현하는 방법에 대한 의사 결정을 내리는 일관된 규칙’을 갖추는 것이다.

2. 모범 사례를 만드는 이유

조직만의 IAM 규칙(모범 사례)을 만들어 두면 아래 3가지의 강력한 이점을 얻을 수 있다.

1. 의사 결정 시간 절약
   1. 매번 새로운 권한을 줄 때마다 보안과 편의성을 저울질하며 평가하는 것은 업무를 크게 지연된다.
   2. 해결책 : 초기에 한 번만 치열하게 논의하여 규칙(모범 사례)을 만들어두면, 이후에는 고민 없이 규칙만 따르면 되어 시간을 아낄 수 있다.
2. 일관성 유지
   1. 보안 결정은 주관적이라서 규칙이 없으면 담당자마다 다르게 권한을 부여해 시스템 전체가 뒤죽박죽이 된다.
   2. 해결책 : 전사적으로 권한 부여 방식을 하나로 통일하면, 특정 사용자가 어떤 권한을 가졌는지 누구나 쉽고 빠르게 파악할 수 있다.
3. 측정 대상(감사 기준) 제공
   1. 외부에서 보안 감사를 요구할 때 우리 시스템이 안전한지 증명하려면, 먼저 조직 내 ‘안전한 구성’에 대한 명확한 기준이 있어야 한다.
   2. 해결책 : 모범 사례가 곧 이 채점 기준표가 되며, 실제 리소스들이 이 기준에 얼마나 잘 맞춰져 있는지 확인하여 보안 수준을 평가할 수 있다.

조직만의 IAM 모범 사례를 만드는 것은 단순한 문서 작업이 아니라, ①업무 속도를 높이고, ②관리를 파악하기 쉽게 통일하며, ③외부에 우리 시스템이 안전함을 증명할 수 있는 채점 기준표를 만드는 일이다.

3. 모범 사례 예: MFA

1. MFA의 강력한 보안과 치명적인 단점
   1. MFA (OTP 앱, 물리적 토큰 등)는 비밀번호와 기기를 모두 훔쳐야 하므로 해킹을 방어하는 데 매우 탁월하다.
   2. 하지만 로그인할 때마다 번거롭고, 휴대폰 배터리가 방전되거나 기기를 분실하면 로그인할 수 없다.
2. 모두에게 강제하는 것이 정답일까?
   1. “모든 사용자에게 MFA를 요구한다”는 원칙이 바람직해 보이지만, 우리 조직의 상황(위협 모델)에 맞는지 먼저 확인해야 한다.
   2. 위험도가 낮은 일반 사용자 100명과 위험도가 매우 높은 관리자 3명이 있다면, 모두에게 적용하는 것은 100명에게 불편함만 초래할 수 있다.
3. 최적의 타협점 (조직에 맞는 모범 사례 도출)
   1. ‘보안 이점이 적은 100명 대신, 고위험 권한을 가진 관리자 3명에게만 MFA를 요구한다’는 규칙을 세울 수 있다.

4. 강제 적용 가능한 모범 사례

• 모범 사례(규칙)를 만드는 것과 그것을 실제로 시스템에 적용하는 것을 별개의 문제이다.

• 전체 사용자 계정에 적용되는 ‘비밀번호 정책’과 같은 몇 가지 일반적인 모범 사례는 IAM 내에서 쉽게 적용할 수 있다.

• 비밀번호 정책은 최소 길이나 대소문자, 숫자, 특수 문자 등의 특정 규칙을 요구하여 무차별 대입(Brute force) 공격을 어렵게 만들고, 일정 기간 후 비밀번호가 만료 되도록 할 수 있다.
  

비밀번호 정책 옵션	보안 이점
필수 : 대문자, 소문자, 숫자, 기호 또는 최소 길이	- 비밀번호의 엔트로피(복잡도)를 높여 추측하거나 무차별 대입하기 어렵게 한다. - 이를 통해 공격자가 계정의 IAM 사용자로 접근 권한을 얻을 위험이 줄어든다.
최대 비밀번호 사용 기간	일정 기간이 지나면 비밀번호가 만료되어, 공격자가 이전의 도난된 자격증명(비밀번호)을 사용해 계정에 접근할 위험을 줄인다.
비밀번호 재사용 방지	- 사용자가 최근에 사용한 비밀번호를 다시 쓰지 못하도록 한다. - 최대 비밀번호 사용 기간과 함께 사용하여 공격자가 이전 자격증명으로 접근할 위험을 줄인다. - 만약 사용자가 만료된 이전 비밀번호를 재사용할 수 있다면 이전의 도난된 자격증명은 여전히 위험하다.

4.1. AWS CLI를 사용하여 강제 적용

• 안전한 비밀번호 정책에 대한 모범 사례 예시로, 한국인터넷진흥원의 ‘패스워드 선택 및 이용 안내서’를 이용한다.
  • 최소 여섯 자리 이상 문자
  • 최소 한 자리 이상 숫자
  • 6개월마다 변경
• IAM 비밀번호 정책 생성
  • --minimum-password-length 6 : 비밀번호에 여섯 자 길이가 필요함을 의미
  • --require-numbers : 최소 하나의 숫자가 포함되어야 함을 의미
  • --max-password-age 180 : 180일(6개월)마다 비밀번호가 만료되도록 설정

      $ aws iam update-account-password-policy \
      --minimum-password-length 6 \
      --require-numbers \
      --max-password-age 180
    

4.2. AWS IAM Console을 사용하여 강제 적용

명령어 기반의 CLI가 아닌 웹 콘솔을 통해서도 동일한 작업을 수행할 수 있다.

1. IAM 콘솔의 왼쪽 메뉴에서 계정 설정(Account Settings)을 선택
2. Password policy 영역에서 비밀번호 정책 변경(Change password policy)** 버튼을 클릭
3. 강제 적용할 정책을 선택하는 화면에서 앞서 설명한 정책을 활성화하도록 체크박스와 값을 입력
   • [v] Enforce minimum password length: 6 characters
   • [v] Require at least one number
   • [v] Enable password expiration: Expire passwords in 180 day(s)

4.3. 규칙 별 적용 시점 차이

정책을 적용할 때 규칙의 종류에 따라 적용되는 시점이 다르다. 이를 반드시 인지하고 정책을 구성해야 한다.

• 즉시 적용되는 규칙 (비밀번호 만료)
  • 설정하는 순간 바로 검사를 수행한다.
  • 이미 180일 넘게 비밀번호를 안 바꾼 사람은 다음 로그인 때 강제로 비밀번호를 바꿔야만 들어갈 수 있다.
• 나중에 적용되는 규칙 (문자열 복잡도)
  • 지금 당장 로그인하는 걸 막지는 않는다.
  • 하지만 사용자가 나중에 비밀번호를 ‘새로 바꿀 때’가 오면, 그때부터는 무조건 바뀐 빡빡한 규칙(숫자 포함 등)에 맞춰서 만들어야 한다.