Trusted Advisor – Security 분야 자세히 보기
안녕하십니까, GS네오텍 최준승입니다.
지난 히스토리 먼저 소개드립니다.
AWS Trusted Advisor 활용하기
Trusted Advisor – Cost Optimization 분야 자세히 보기
Trusted Advisor – Performance 분야 자세히 보기
보시다시피 이 포스팅은 시리즈로 진행하고 있습니다.
Cost : Cost Optimization
Perf : Performance
Sec : Security
Fault : Fault Tolerance
Limit : Service Limits
오늘은 자세히 보기 3회차로 Security 분야를 다룹니다. 항상 제일 중요하다고 말하면서도 뭔가 소외된 느낌의 바로 그 보안입니다.
각 항목은 가독성을 위해 중요도에 따라 순서를 제 임의대로 재배열하였습니다.
▲ 노란색은 주의항목이고 ◎ 빨간색은 경고항목입니다.
`18년 9월 기준으로 항목은 총 17가지입니다.
그럼 시작!
Security
[Sec-01] Amazon S3 Bucket Permissions
▲ “익명 사용자에게 읽기/리스팅 권한이 부여된” S3 버킷이 있다 ◎ “익명에게-쓰기 권한이 부여된” S3 버킷이 있다
※ 대안: open access 설정을 의도한 것이 아니라면 특정 사용자만 접근할 수 있도록 권한 정책을 조정한다
[Sec-02] Exposed Access Keys
◎ 인터넷 상에(ex: Github) 해당 계정 內 객체의 Access Key쌍이 노출되었다(또는 노출된 정황이 있다)
※ 대안: 해당 키쌍을 즉시 삭제하고, 해당 키쌍을 통해 계정내에 오용된 리소스가 없는지 확인한다
[Sec-03] MFA on Root Account
◎ 해당 계정의 Root Account에 MFA가 설정되어 있지 않다
※ 대안: Root Account에 MFA를 설정한다
[Sec-04] IAM Use
▲ 해당 계정 內에 생성된 IAM User 객체가 하나도 없다
※ 대안: Root Account만 사용하지 말고, 복수의 IAM User 객체를 만들어 사용자별로 권한을 적절히 제어한다
[Sec-05] IAM Password Policy
▲ IAM 객체의 암호 정책(암호 최소길이 등)이 부분적으로 설정되어 있다 ◎ 암호 정책이 비활성화 상태다
※ 대안: 필요한 항목을 검토한 후 적절한 암호 정책을 설정한다
[Sec-06] IAM Access Key Rotation
▲ “교체(Rotation) 시점이 최근 90일 이상 2년 미만인” Access Key쌍이 있다 ◎ “~ 2년 이상인” 키쌍이 있다
※ 대안: 해당 키쌍을 주기적으로 교체(Rotation)한다
[Sec-07] Security Groups – Unrestricted Access
◎ “22/80/443번 외 Port를 대상으로 Source IP가 Any인 룰이 포함된” Security Group이 있다
※ 대안: Source IP가 Any로 설정된 룰을 삭제하거나 특정 IP(또는 Range)로 제한하는 정책을 설정한다
[Sec-08] Security Groups – Specific Ports Unrestricted
▲ “일부 Port가 Any로 열린” SG가 있다 ◎ 20/21/1433/1434/3306/3389/4333/5432/5500 Port가 Any로 열려있다
※ 대안: Source IP가 Any로 설정된 룰을 삭제하거나 특정 IP(또는 Range)로 제한하는 정책을 설정한다
[Sec-09] ELB Security Groups
▲ “Listener 설정에 없는 Port로 Inbound Access가 설정된” ELB SG가 있다 ◎ ELB에 설정된 SG 객체가 없다
※ 대안: ELB의 Listener 설정에 존재하는 Port 정보를 기반으로 Security Group 룰을 설정한다
[Sec-10] ELB Listener Security
▲ “앞단에 암호화 Protocol 미사용 or 부적절한 Cipher/Protocol을 적용한” ELB ◎ 취약한 Cipher/Protocol 적용 ELB
※ 대안: Front-End에는 HTTPS나 SSL 프로토콜을 설정하고 최신(또는 적합한 수준의) SSL Security Policy를 사용한다
[Sec-11] Amazon RDS Security Group Access Risk
▲ “주요 Port가 Any로 열린 EC2 SG를 참조 or Single IP로 제한X인” RDS SG가 있다 ◎ Any 정책의 RDS SG가 있다
※ 대안: RDS에 매핑된 Security Group에 특정 IP로 접근을 제한하는 룰을 설정한다
[Sec-12] AWS CloudTrail Logging
▲ 특정 Cloudtrail log를 가져오는데 실패했다 ◎ 해당 Region에 Cloudtrail 로깅 설정이 되어있지 않다
※ 대안: Cloudtrail을 활성화하고, 지정한 S3 Bucket에 로깅 관련 권한이 부여되어 있는지 확인한다
[Sec-13] Amazon EBS Public Snapshots
◎ “Public으로 공개된 상태의” EBS 스냅샷이 있다
※ 대안: 의도적으로 Public하게 공개한 것이 아니라면, 특정 AWS 계정의 ID로 제한하여 스냅샷의 권한을 조정한다
[Sec-14] Amazon RDS Public Snapshots
◎ “Public으로 공개된 상태의” RDS 스냅샷이 있다
※ 대안: 의도적으로 Public하게 공개한 것이 아니라면, 특정 AWS 계정의 ID로 제한하여 스냅샷의 권한을 조정한다
[Sec-15] CloudFront Custom SSL Certificates in the IAM Certificate Store
▲ “부적합(SHA-1/CNAME)하거나 7일내 만료 예정인” Custom SSL 인증서가 CF에 매핑 ◎ 매핑된 인증서 만료
※ 대안: 만료된 인증서를 갱신하거나 SHA-256 해시 알고리즘 사용 및 Alternative Domain에 매칭되는 인증서를 사용
[Sec-16] CloudFront SSL Certificate on the Origin Server
▲ “부적합(SHA-1/CNAME)하거나 7일내 만료 예정인” 오리진 SSL 인증서가 있다 ◎ 오리진 인증서 만료
※ 대안: 만료된 인증서를 갱신하거나 환경에 적합한 인증서를 Cloudfront 원본(Origin)에 등록
[Sec-17] Amazon Route 53 MX Resource Record Sets and Sender Policy Framework
▲ MX 리소스 레코드에 “SPF 설정을 포함한 TXT 리소스 레코드”가 등록되어 있지 않다
※ 대안: 해당 레코드를 등록한다
아. 정말 제한된 글자수 내에서 뭔가를 요약하기가 힘이 드네요.
클라우드 보안과 관련된 첨언을 좀 드리면
클라우드 환경에서의 제어할 수 있는 권한의 범위는 실로 방대합니다.
예를 들어 아래 3가지 Action 모두 AWS API로 제어하는 것들이고, 따라서 IAM에서 권한 관리를 해야 합니다.
- DynamoDB 서비스를 제어할 수 있는 객체(IAM User)를 만든다
- DynamoDB에서 신규 테이블을 만든다
- DynamoDB에서 신규 Item을 추가한다
3가지 Action의 계층이 모두 다르다는게 이해가 가시나요?
암튼 이걸 세밀하게 제어해야 되는데. 말처럼 쉽지가 않죠. 이유는 여러가지가 있습니다만.. 패스하고.
아무튼 Trusted Advisor의 Security 항목은
현재 내 계정의 구성에서 보안적으로 취약한 항목을 비록 일부긴 하나 확인(이라고 쓰고 환기라고 읽는다)할 수 있는 기회를 제공합니다.
써보신 분은 아시겠지만. 특정 이벤트는 Exclude 처리도 가능하다고 하니 잘 활용해 보시구요.
오늘 포스팅은 제 60번째 포스팅이네요. 올해까지 70개가 목표입니다.
마치겠습니다. 그럼 끝!
최신 댓글