AWS에 포커스를 맞추고 학습하지 않는 이상 해당 분야에 대한 지식 수준은 편차가 생긴다.
아는 사람은 당연하게 여기는 사항을 모르는 사람은 존재도 모를 수 있다.
중요하고 당연하지만 모를 수 있는 요소들은 무엇이 있나 확인해보자.
- AWS 루트 계정 2차 인증 설정
AWS 가입에 사용한 그 이메일이 루트 계정이다. 결론부터 말하면, 이 계정을 사용하는 것은 권장하지 않는다.
최상위 권한을 가진 사용자라 계정 폐쇄까지 가능한 사용자다. 누가 들어와서 탈퇴해버릴 수 있다는 것.
2차 인증(MFA) 설정을 활성화한 후 사용하지 않는 것이 좋다.
그럼 뭘로 접속해서 관리하나? IAM에서 AdministratorAccess 권한을 가진 사용자를 생성해 접속하면 된다.
물론 이 사용자도 2차 인증을 활성화해야 한다.
MFA 설정 시 백업 필수.
- 기본 네트워크 리소스는 사용하지 말 것.
처음 VPC 서비스쪽을 둘러보면 기본 VPC, 기본 Subnet 등의 기본 네트워크 리소스가 만들어져 있다.
기본 네트워크 리소스는 CIDR 수정이 불가능하다. 이처럼 커스터마이징에 제한이 걸리는 점이 있어 추후 확장성 등을 고려하면 시작부터 사용하지 않는 것이 좋다.
- 테스트 환경과 서비스 환경을 분리할 것.
여기서 환경 분리, 라고 하면 최소 VPC 분리다.
실리적으로 보면 CloudTrail, CloudWatch 등의 모니터링 서비스에서 로그/트래픽이 섞이는 것을 방지하기 위해서다.
리소스 관리 측면에서도 분리하는 것이 낫다.
그리고 규정 준수 목적도 있다. ISMS 시스템 개발보안 인증 기준 중, 다음과 같은 항목이 있다.
- "개발/시험 시스템을 운영 시스템과 분리하고 있는가?"
그러니 나중에 규정 준수 챙긴다고 공수 들이지 말고, 미리 분리해놓는 것이 좋다.
분리하면 관리할 규모가 늘어나 좋지 않다, 라고 할 수도 있는데...몇몇 기업들은 서비스 기능을 쪼개 다른 계정으로 분산시키는 경우도 있을 만큼 '분리' 도 나름 중요한 키워드다.
- 사용 중인 서비스의 설정들을 잘 활용하고 있는가?
AWS에는 관리형 서비스들이 많다. 특정 서비스를 사용하고 있을 때, 해당 서비스에서 제공하는 옵션들을 충분히 활용하고 있는지 검토하는 것이 좋다.
가용성/장애 복구 등 많은 사용자들이 원할 법한 기능들은 각 서비스에서 대부분 제공하고 있다.
저런 부분 챙긴다고 뭘 개발하거나 SW를 사서 쓰지 말고, 일단 제공되는 옵션들을 확인하자.
- 네트워크 공개 수준을 인지하고 있는가?
별거 아니다. 민감한 리소스를 퍼블릭으로 열어놨는지, 프라이빗에 박아놨는지 인지하라는 것이다.
보안적으로도 중요한 요소이기에 자신이 지금 굴리고 있는 리소스들이 어떤 상태인지 확인할 필요가 있다.
- 이중화/가용성을 챙기고 있는가?
어떤 이유에서든 고객에게 서비스 중인 인프라에 장애가 생길 가능성은 열어둬야 한다.
예를 들면 무작정 EC2 인스턴스 유형을 키우기 전에 Auto Scaling을 적용했는지 확인이 필요하다는 것.
더 기억나는대로 업데이트 예정.
'AWS' 카테고리의 다른 글
Lambda, SQS, SNS (1) (0) | 2022.06.14 |
---|---|
RDS 스냅샷 복구 관련 테스트 (0) | 2022.06.02 |
EC2에서 MySQL 5.5 테스트 (2) (0) | 2022.05.16 |
EC2에서 MySQL 5.5 테스트 (1) (0) | 2022.05.12 |
AWS DB 공부 일정 (0) | 2022.05.01 |
댓글