[AWS-Security] 4.3. 최소 권한 접근 제어 적용

1. 개요

1.1. 최소 권한의 원칙

• 개념 : 작업을 수행하는 데 필요한 최소한의 권한만 부여해야 한다는 강력한 보안 원칙이다.
• 은행 금고 비유 : 고객이 은행에서 금고 상자 10개를 구매하면, 그 10개의 상자만 열 수 있는 열쇠 10개를 받는 것이 정상적이고 안전한 방식이다.
• 최소 권한이 깨지는 상황 : 만약 고객이 열쇠 10개를 관리하기 귀찮다고 불평하여 은행원이 은행 내의 모든 금고 열쇠를 열 수 있는 마스터키를 줘버린다면, 고객은 다른 사람의 상자까지 열 수 있는 엄청난 권한을 갖게 된다.

1.2. 과도한 권한 = 책임과 위험의 증가

이 원칙의 근본적인 아이디어는 부여된 모든 권한은 곧 그 사용자의 책임이자 시스템의 위험이라는 것이다.

• 실수 (휴먼 에러)
  • 실제 서비스되는 프로덕션 데이터베이트 테이블 삭제 권한이 있다고 가정한다.
  • 이 사용자가 실수로 잘못된 명령을 입력하면 모든 서비스가 중단된다.
  • 실제로 AWS 역사상 가장 눈에 띄는 대규모 장애 중 하나(Amazon S3 서비스 1시간 이상 중단)가 이런 간단한 직원의 실수로 인해 발생한 적이 있다.
• 악의적 공격 (스푸핑, 내부자 위협)
  • 권한이 많은 게정이 해커에게 탈취당하거나, 혹은 내부 직원이 앙심을 품고 의도적으로 데이터를 삭제할 경우 그 피해는 걷잡을 수 없이 커지게 된다.

1.3. 보안과 편의성의 스펙트럼

• 가장 안전한 방법 : 아무에게도 권한을 부여하지 않으면 아무런 동작을 수행할 수 없기 때문에 가장 안전하다. 하지만 필요한 작업마저도 할 수 없게 된다.
• 가장 편리한 방법 : 모든 사람에게 관리자 권한을 부여한다. 하지만 이는 매우 위험한 방법이다.
• 차선책 (최소 권한의 원칙) : 절대적으로 필요한 권한만 부여하는 방법을 선택해야 한다.

2. 최소 권한 원칙이 어려운 이유

2.1. 정책 작성의 어려움 (리소스 지정의 까다로움)

• 상황 : 개발자에게 EC2 인스턴스를 생성하고 삭제할 권한을 주어야 한다.
• 문제 : 정책의 리소스 블록에 * (모든 리소스)를 쓰면, 개발자는 자신이 담당하지 않는 다른 제품의 인스턴스까지 삭제할 수 있게 되어 최소 권한 원칙에 위배된다.
• 현실적 한계
  • 특정 인스턴스 이름만 지정하면, 인스턴스가 새로 생성되거나 삭제될 때마다 매번 정책을 수정해야 한다.
  • 속성 기반 접근 제어(태그 기반 제어)를 쓸 수도 있지만, 항상 올바른 태그가 붙어 있는지 확인해야 한다.

2.2. 필요한 권한 확인의 어려움 (프로토타이핑과 요구사항 변경)

• 상황 : 개발팀이 새 애플리케이션의 프로토타입을 만들고 있다.
• 문제 : 프로토타이핑의 경우, EC2 -> ECS -> Lambda 등 부여해야 하는 권한이 빈번하게 변경된다.
• 현실적 한계
  • 서비스 변경이 잦은데, 그때마다 권한을 수정한다면 개발 속도가 현저히 느려진다.
  • DynamoDB에 데이터를 쓸 때도 단순히 ‘업데이트’인지 ‘전체 교체’인지에 따라 필요한 세부 권한도 모두 다르다.
  • 이를 사전에 정확히 파악하여 결정하기가 매우 어렵다.

2.3. 시행(감사 및 확인)의 어려움

• 상황 : MFA 적용과 같이 규칙 준수 여부를 확인하고 싶은 경우, MFA는 사용자 목록을 뽑아서 켰는지만 확인하면 된다.
• 문제 : 반면 모든 사용자에게 최소 권한이 잘 적용되었는지 확인하려면, 각 사용자의 ‘현재 권한’과 ‘실제로 필요한 권한’을 일일이 비교해야 한다.
• 현실적 한계
  • 사용자가 가진 모든 권한을 파악하려면 여러 정책을 일일이 확인해야 한다.
  • 사용자에게 실제로 필요한 권한이 무엇인지 알아내려면 코드 리뷰, 사용자와의 면담, 로그 분석, 리소스 검사 등 많은 시간과 노력이 든다.
  • 모든 것을 확인하더라도 모든 작업이나 리소스를 100% 놓치지 않았다고 확신할 수 없다.

3. 와일드카드 정책

3.1. 와일드카드(*)의 위험성 (보안의 관점)

• Action: dynamodb:*, Resource: *처럼 와일드카드를 쓰면 짧은 코드로 모든 권한을 쉽게 줄 수 있지만, 사용자가 전혀 쓰지 않는 수십 가지의 불필요한 기능(테이블 삭제, 백업 설정 등)까지 허용하게 된다.
• “필요한 권한만 준다.”라는 최소 권한의 원칙에 위배되며, 해킹이나 실수 발생 시 피해 규모를 키우는 원인이 된다.

3.2. 와일드카드를 포기했을 때의 고통 (편의성의 관점)

• 와일드카드를 쓰지 않고 하나하나 명시하려면, 코드가 길어지고 읽고 리뷰하기 어려워진다.
• 리소스의 ARN을 하나하나 알아야 하고, 서비스 이름(소문자)과 작업 이름(파스칼 표기법)을 오타 없이 정확히 맞춰야 한다.

3.3. 상황에 따른 유연한 적용 (모범 사례)

• 무조건 와일드카드를 금지하는 것이 정답은 아니다. (ex. 모든 테이블의 백업 상태를 점검해야 하는 경우, *를 사용하는 것이 바람직하다.)
• 조직은 와일드카드를 금지해서 얻는 보안 상의 이점이, 편의성을 포기하고 개발 속도가 느려지는 손실을 감수할 만큼 중요한지를 비교하며 정해야 한다.

4. AWS 관리형 정책

4.1. 관리형 정책의 보안 취약점 (최소 권한 위배)

• AmazonEC2FullAccess 같은 관리형 정책은 사용자가 전혀 쓰지 않을 400개 이상의 모든 EC2 작업을 허용한다.
• 와일드카드(*)를 쓰는 것과 마찬가지로 ‘최소 권한의 원칙’에 크게 위배된다.

4.2. 관리형 정책의 압도적 편의성

• 정책을 직접 짤 필요가 없어 작성 속도가 빠르고, 오타로 인해 예기치 못한 오류를 일으킬 실수를 원천 차단한다.
• AWS 측에서 새로운 읽기 기능 등을 출시할 때마다 정책이 자동으로 업데이트되므로 관리자가 일일이 수정할 필요가 없다.

4.3. 관리형 정책을 금지할 경우 장단점

• 보안 이점
  • 과도한 권한의 위험을 줄인다.
  • 관리형 정책은 광범위하며 필요한 권한을 항상 정확하게 매핑하지는 않는다.
• 편의 비용
  • 모든 정책을 직접 작성하고 검토하는 데 시간이 오래 걸린다.
  • 자체 정책을 작성하는 경우 실수가 발생할 가능성이 더 크다.
  • AWS 서비스가 업데이트될 때마다 정책도 수동으로 업데이트해야 한다.

5. 공유 권한 금지

5.1. 모든 공유 권한 (그룹/관리형 정책) 금지의 의미

• 이 모범 사례는 앞서 배운 ‘최소 권한의 원칙’을 가장 극단적으로 적용한 예시이다.
• 그룹이나 공통으로 쓰는 관리형 정책을 아예 쓰지 않고, 오직 상요자 1명 당 딱 맞는 전용 권한만 개별적으로 만들어 부여하는 방식이다.

5.2. 보안 논리와 현실적인 한계

• 보안 논리 : A라는 사람을 위해 그룹 정책을 수정하면, 그 권한이 전혀 필요 없는 같은 그룹의 B에게도 불필요한 권한이 생기게 된다. 이를 막고 개개인에게 완벽한 ‘최소 권한 집합’을 제공하기 위한 목적이다.
• 현실적 한계 : 이 방식은 직원 수 만큼 정책을 짜고 관리해야 하므로 추가 작업이 필요하다.