25탄-(요약) AWS 보안 - 계정 관리
SK 쉴더스 보안가이드를 참고해서, 하나씩 요약해봅니다.
실무에서 사용했던 경험을 추가합니다.
본 내용은 개인적으로 정리한 내용이라 틀릴 수 있습니다.
<1> 사용자 계정 관리
<2> 1인 1계정의 원칙
<3> Access-key는 별도로 만들어 사용하자.
<4> Pem키를 통해 EC2에 접속하자.
<5> Pem 키를 퍼블릭 s3나 EC2 서버에 올려놓지 않도록 한다.
<6> 개발자에게 ADMIN 권한을 제공하지 않는다.
<7> Access-Key는 6개월마다 교체되어야 한다.
<8> 2차 인증은 필수이다.
<9> 법적 요건에 맞는 콘솔 패스워드 정책을 설정해야 한다.
<10> 실습
<1> 사용자 계정 관리
1
Console ROOT 계정?
AWS Account ID 생성하면 기본으로 ROOT 계정을 사용한다.
일반적으로 ROOT 계정은 사용하지 않도록 하고, 별도 IAM계정을 만들어 admin권한을 부여해 사용한다.
ROOT계정은 해당 Account ID를 종료시킬 수 있다. ROOT만 할 수 있는 기능들이 몇 개 있다.
ROOT계정은 탈취시 큰 문제가 되므로 반드시 2차 인증을 설정하자.
2차 인증은 하드웨어 MFA, 스마트폰에 MFA , 크롬 브라우저에 MFA 설치로 사용할 수 있다.
일반적으로 스마트폰에 MFA를 사용한다.
MFA는 내부 별도 MFA 저장소에 보관하여, 다른 팀원들도 내부에서 사용할 수 있도록 하자.
ROOT 사용자를 위한 Access-key는 절대 만들지 않도록 한다.
2
IAM 계정?
일반 사용자 계정이다.
개발자가 계정을 요청하면 IAM 계정을 만들어준다.
관리자도 IAM 계정을 만들고, ADMIN 권한을 할당받아 사용한다.
IAM 콘솔 로그인 URL 은 따로 있다. ROOT 로그인 화면과 틀리다.
3
AD(Active Directory)?
통합 계정으로 내부 시스템과 AWS도 한번 로그인으로 같이 사용할 수 있게 가능하다.
내부 인사 시스템 AD와 AWS 사용을 위한 ADFS와 연동한다.
AWS에서는 ADFS를 통해 사용한다.
이 경우 role을 받아와 사용하게 된다.
퇴사자인 경우 내부 인사 시스템 AD에서 지워지므로 , 자연스럽게 AWS에 로그인도 불가능해진다.
AD와 AWS를 연동하지 않으면, 퇴사자 발생의 경우 즉시 확인하기 어렵다.
AD를 사용하지 않으면, AWS IAM 계정에 대해 주기적으로 퇴사자 발생에 대해 점검을 해야 하는 단점이 있다.
4
Access-key?
원격에서 CLI로 리소스를 생성, 삭제하는 계정이다.
발급을 최소화해야 한다.
팀단위로 1개 정도 발급한다.
최소 권한을 부여한다. 예를 들어 생성 권한과 조회 권한만 제공하고, 삭제 권한은 부여하지 않는다.
Admin 권한을 줄경우, 특정 IP에서만 사용가능하도록 반드시 제어하도록 하자.
과징금을 받는 수도 있다.
종종, GIT에 Access-key 가 올라가 해킹을 당하는 수가 있다.
5
IAM, 그룹의 권한 확인?
admin권한을 개발자가 가지고 있지 않도록 한다.
여러 명이 admin 권한을 가지고 있지 않도록 한다.
<2> 1인 1계정의 원칙
1
한 사람은 1개의 IAM 계정만 가지도록 한다.
2
해당 콘솔 계정은 누가 사용하는지 반드시 확인 가능해야 한다.
태그를 붙이던 해야 한다.
사용자를 모르는 계정이 존재해서는 안된다.
3
사내 AD를 연동하면, 사용자 확인이 가능하므로 태그등은 작성하지 않아도 된다.
4
공동으로 사용하는 계정은 없어야 한다.
<3> Access-key는 별도로 만들어 사용하자.
1
IAM 콘솔 계정에 Access-key를 같이 할당하지 않도록 한다.
콘솔 계정을 퇴사 시 삭제된다.
Access-key 가 콘솔 IAM 계정과 같이 사용하고, 서비스로 사용되고 있으면 삭제 시 서비스 장애가 발생한다.
2
Access-key는 반드시 태그를 달도록 하자.
누가 사용하고, 어떤 용도 인지 등 기록해야 한다.
추후 문제시 사용자 확인이 가능해야 한다.
<4> Pem키를 통해 EC2에 접속하자.
1
일반 계정과 암호로 서버에 접속하지 않도록 하자.
2
예외)
서버 접근 제어 시스템이 계정과 암호로 접속되도록 되어 있는 경우가 있다.
이는 보안이 되어 있는 시스템이라 계정과 암호로 접속 가능하다.
참고
pem키로 로그온 하는 시스템을 계정/암호 방식으로 변경하는 스크립트 첨부.
<5> Pem 키를 퍼블릭 s3나 EC2 서버에 올려놓지 않도록 한다.
Pem 키가 탈취당하면 서버의 제어권도 탈취당한다.
<6> 개발자에게 ADMIN 권한을 제공하지 않는다.
ADMIN권한은 인프라를 관리하는 사용자만 가지도록 한다.
개발자에게 제공 시 모든 권한을 가지게 되므로 문제가 될수 있다.
<7> Access-Key는 6개월마다 교체되어야 한다.
1
Access-Key는 계정당 2개씩은 동시에 사용할 수 있다.
1개 사용하다 추가 발급받고 교체하도록 하자.
2
많은 권한을 가진 Access-key는 특정 IP에서만 사용 가능하도록 제한되어야 한다.
모든 곳에서 사용이 가능혀면 안 된다.
법적으로 과장금 대상이다.
"개인정보 보호법규 위반 제재" 첫 사례
관리자 접근권한을 IP, 즉 인터넷에 연결된 기기를 식별하는 고유번호로 구별하지 않은 것으로 드러났습니다.
특히, 권한 없는 자가 접근만 확보하면, 외부 인터넷 어디서나 접속할 수 있도록 운영해, 개인정보가 유출되거나 제3자가 열람한 것으로 밝혀졌습니다.
출처 : BBS NEWS(https://news.bbsi.co.kr)
<8> 2차 인증은 필수이다.
1
ROOT 계정?
2차 인증 필수
Access-key는 만들지 않는다.
2
IAM 계정?
2차 인증 필수
3
AD 연동?
가능하다면 AD연동하여 사용자를 관리한다.
4
Access-key?
발급을 최소화한다.
콘솔 계정과는 별도로 Access-key를 발급하도록 한다.
6개월 이 넘는 키는 교체하도록 한다.
실습)
만들어 보자.
1단계, 2단계 2번 해야 한다.
<9> 법적 요건에 맞는 콘솔 패스워드 정책을 설정해야 한다.
1
IAM에서 설정한다.
2
AD연동 시는 AD정책을 따르게 된다.
<10> 실습
1
위 기본 내용을 실습해보자
2
ISMS 기준 실습
https://brunch.co.kr/@topasvga/749
3
IAM 실습
https://brunch.co.kr/@topasvga/1760
4
같이 볼만한 자료
https://brunch.co.kr/@topasvga/2929
감사합니다.
