[AWS-Security] 4.1. 조직 요구사항에 따른 모범 사례

1. 개요

모든 보안 기능에는 장단점이 있으므로, 맹목적으로 적용하기 보다는 조직의 상황에 맞게 아래 사항들이 반드시 고려되어야 한다.

• 최소 권한 접근 제어 적용
• 보안과 편의성의 균형
• 주기적인 보안 검토

2. 위협 모델링

• 공식적인 위협 모델링 프로세스가 있든 없든, 위협 모델은 가장 가능성이 높은 공격 벡터와 가장 취약한 자산으로 구성된다.
  

• 예를 들어, AWS 환경을 혼자서 운영하는 경우 내부자 위협은 타당한 공격 시나리오가 아니며, 위협 모델의 일부가 되지 않는다.
  

• 모든 모범 사례는 위협 모델의 맥락에서 고려해야 한다. 모범 사례는 가장 취약하고 중요한 자산을 보호하고 가장 가능성이 높은 공격을 방지해야 한다.

2.1. 위협 모델의 도입

1. 먼저 애플리케이션의 아키텍처 다이어그램 작성으로 시작한다.
   1. 모든 데이터 소스의 경우 데이터가 얼마나 민감한 정도를 표시한다.
   2. 통신하는 두 서비스의 경우 어떤 종류의 데이터가 전달되는지를 지정한다.
2. IAM의 주된 구성 목록(ex. 사용자, 그룹, 역할 등)을 작성한다.
   1. 민감한 데이터 또는 기타 중요한 리소스에 접근할 수 있는 것이 어떤 것이 있는지를 지정한다.
3. 무엇이 잘못될 수 있는지 생각한다.
   (약간의 창의성이 필요하며, 단순하지 않다. STRIDE 모델을 사용할 수 있다.)

2.2. STRIDE 모델

• S (Spoofing - 스푸핑) : 공격자가 사용자의 비밀번호에 대한 무차별 대입 공격을 할 수 있는가?
• T (Tampering - 변조) : 공격자가 고객과 애플리케이션 간의 전송 데이터를 변조할 수 있는가?
• R (Repudiation - 부인) : 공격자가 흔적을 지우기 위해 접근 로그를 삭제할 수 있는가?
• I (Information Disclosure - 정보 공개) : 공격자가 비밀 S3 버킷에서 데이터를 읽을 수 있는가?
• D (Denial of service - 서비스 거부) : 공격자가 가짜 요청으로 애플리케이션을 과부하시킬 수 있는가?
• E (Elevation of privileges - 권한 상승) : 공격자가 접근이 허용되지 않아야 하는 리소스에 접근할 수 있는가?
  (IAM에서 가장 중요한 부분)

스푸핑과 무차별 대입 공격은 엄연히 다른 공격 기법이다. 하지만 여기서는 AWS IAM 입장에서 공격자가 위장해 정상적으로 로그인할 수 있는가?에 대한 일련의 공격 과정을 스푸핑으로 표현하였다.

3. 편의성

• 보안을 강화할수록 필연적으로 시간, 비용, 또는 사용성의 불편함(편의 비용)이 발생한다.
• 조직은 무작정 최고 수준의 보안을 고집할 것이 아니라, 얻게 되는 ‘보안 가치’와 잃게 되는 ‘편의성’ 사이에서 합리적인 타협접을 찾아야 한다.

3.1. IAM 보안 정책 도입 시 발생하는 딜레마

AWS 실무 사례	보안 가치	편의 비용
AWS 관리형 정책 대신 자체 정책 작성	- AWS가 미리 만들어둔 범용적인 권한 대신, 우리 회사 서비스에 딱 맞는 권한만 세밀하게 부여할 수 있다. - 이는 해킹 피해를 최소화하는 ‘최소 권한 원칙’을 달성하는 데 유리하다.	- 보안 담당다자 일일이 정책을 JSON 형식으로 작성하고 검토해야 하므로 시간이 오래 걸린다. - 만약 정책을 잘못 작성하면 개발자의 앱 실행이 차단되는 장애가 발생할 위험도 크다.
관련 없는 인프라에 별도의 AWS 계정 사용	개발용 계정과 운영용 계정을 분리해 두면, 해커가 개발용 계정을 탈취하더라도 실제 고객 데이터가 있는 운영 환경에는 접근할 수 없어 피해 범위가 좁아진다.	- 관리해야 할 계정이 늘어나 로그인이나 결제(빌링) 관리가 번거로워진다. - 계정 간에 데이터를 주고 받아야 할 때는 복잡한 ‘교차 계정 권한’을 추가로 설정해야 한다.
강력한 암호 설정	무차별 대입 공격 등을 통한 계정 탈취(스푸핑) 위험을 크게 낮춘다.	사용자가 복잡한 암호를 만들고 기억해야 하는 불편함이 따른다.
90일마다 액세스 키 교체	개발자의 실수로 깃허브(GitHub) 등에 액세스 키가 유출되더라도, 90일이 지나면 무용지물이 되므로 해커가 시스템을 장악할 수 있는 시간을 줄여준다.	- 개발자들은 3개월마다 번거롭게 키를 새로 발급받아 코드를 수정해야 한다. - 만약 깜빡하고 제때 키를 교체하지 않으면, 그 키를 사용하던 서비스가 갑자기 중단되는 대형 사고가 날 수 있다.
관리자 계정에 대한 MFA 사용 활성화	아이디와 비밀번호가 털리더라도 스마트폰 앱(OTP 등)을 통한 2차 인증이 없으면 해커가 관리자 권한을 얻을 수 없다.	회사 차원에서 모든 관리자에게 인증 수단을 배포하고 교육해야 하며, 관리자들은 매번 로그인할 때마다 스마트폰을 확인해 코드를 입력하는 수고를 감수해야 한다.
사용자가 아닌 그룹 또는 역할에만 정책 연결	‘김개발’이라는 개인에게 직접 권한을 주지 않고 ‘백엔드 개발팀’ 그룹에 권한을 주면, 권한 관리가 체계화되고 실수로 과도한 권한을 줄 확률이 낮아진다.	만약 특정 팀원 단 한 명에게만 하루 동안 필요한 특수한 권한이 생겼을 때, 예외 처리를 해주기가 매우 까다로워진다.

3.2. 결론

• 비용, 개발 속도, 사용자 경험과 같은 경쟁적 이해관계의 맥락에서 장단점을 평가해야 한다.
• 어떤 모범 사례가 가치가 있는지 판단하려면 앞서 파악한 ‘위협 모델’의 수준과 우리 조직이 허용할 수 있는 ‘불편함(편의 비용)’의 크기를 비교해야 한다.