가장 일반적으로 사용자 사이트에서 발생하는 AWS 보안 문제 9가지를 이야기해봅니다.
가장 일반적으로 사용자 사이트에서 발생하는 AWS 보안 문제 9가지를 이야기해봅니다.
권한이 너무 많거나 또는 암호화 강도가 적정하지 않은경우
1. 지나치게 관대한 S3 버킷 권한
Simple Storage Service(S3)를 사용하면 AWS 사용자가 안정적이고 저렴한 방법으로 데이터를 저장하고 검색할 수 있습니다. 사용자는 데이터를 저장할 지역을 선택하고 해당 지역 내에 버킷을 생성한 다음 버킷에 객체를 업로드합니다. S3 인프라는 선택한 지역 내의 여러 시설에 있는 여러 장치에 개체를 저장합니다. 객체가 저장되면 S3는 손실된 중복성을 신속하게 감지하고 복구하여 내구성을 유지합니다.
S3 버킷은 기본적으로 비공개이지만 관리자는 원하는 경우 버킷을 공개하도록 선택할 수 있습니다. 그러나 사용자가 해당 공개 버킷에 비공개 콘텐츠를 업로드하면 문제가 될 수 있습니다.
또한 AWS 사용자는 S3 버킷 및 객체에 대한 액세스 권한이 있는 사용자와 부여된 권한을 제어할 수 있습니다. AWS 콘솔을 사용하여 다음 피부여자에게 버킷에 대한 액세스 권한을 부여할 수 있습니다.
- 인증된 사용자(AWS 계정이 있는 모든 사람)
- 로그 전달
- 모든 사람(익명 액세스)
이러한 피부여자에게 부여할 수 있는 권한은 다음과 같습니다.
- 목록
- 업로드/삭제
- 권한 보기
- 권한 수정
사용자는 AWS 콘솔보다 더 큰 유연성을 제공하는 사용자 지정 버킷 정책을 생성할 수도 있습니다. 버킷과 버킷에 포함된 객체에 따라 이러한 권한을 부여하는 것이 문제가 될 수도 있고 그렇지 않을 수도 있습니다. 그러나 “모든 사람”에게 권한이 부여된 버킷은 즉시 검토해야 합니다.
누구에게나 공개된 경우 익명 액세스로 인해 데이터가 도난 당하거나 손상될 수 있습니다. 예를 들어 2018년 시만텍은 잘못된 구성으로 인해 S3 버킷에서만 7천만 개 이상의 레코드가 도난당하거나 유출되었음을 발견했습니다 .
2. IAM 사용자에게 직접 권한 부여한 경우
IAM(Identity and Access Management)을 사용하면 AWS 사용자가 AWS 사용자 및 권한을 생성 및 관리하여 계정에 대한 액세스를 제어할 수 있습니다. IAM은 사용자 생성 외에도 그룹 생성을 허용합니다. 그룹에 권한을 부여할 수 있으며 해당 그룹에 속한 모든 사용자에게 특정 권한이 부여됩니다.
이렇게 하면 각 사용자에게 고유한 권한 집합이 없기 때문에 권한 관리가 간소화되고 관리자는 어떤 사용자에게 그들이 속한 그룹별로 어떤 권한이 허용되는지 빠르게 알 수 있습니다. 고유한 권한이 있는 모든 사용자는 해당 권한을 취소하고 대신 그룹에 추가해야 합니다.
3. 의도하지 않은 공개 AMI
Amazon 머신 이미지(AMI)에는 Amazon Elastic Compute Cloud(EC2) 인스턴스를 시작하는 데 필요한 모든 정보가 포함되어 있습니다. 이들은 시작된 인스턴스와 함께 사용될 소프트웨어 구성(운영 체제, 애플리케이션 서버 및 애플리케이션)을 포함하는 템플릿 역할을 합니다. AWS 사용자는 자신의 AMI를 생성하거나, 퍼블릭 AMI를 활용하거나, 사용자 지정 AMI를 구매할 수 있습니다.
사용자가 AMI를 생성하면 AMI를 공개하거나 특정 AWS 계정과 공유하거나 비공개로 만들 수 있는 옵션이 제공됩니다. 퍼블릭 AMI는 모든 AWS 계정에서 시작할 수 있으며 AMI 카탈로그에서 공유됩니다. 그러나 AMI에는 종종 독점 또는 민감한 데이터가 포함되므로 항상 비공개로 설정하는 것이 좋습니다. 공개적으로 액세스할 수 있는 모든 AMI는 신중하게 검토해야 합니다.
4. 암호화 강도 부족
거의 모든 트래픽은 암호화되어야 하지만 특히 금융 및 의료 데이터의 경우에 그렇습니다. 데이터 암호화 및 암호 해독의 성능 저하가 무시할 수 있으며 양식을 제출할 때 웹 사용자 간의 신뢰를 보장합니다. 이를 전송 중 암호화라고 합니다.
또한 스토리지 어레이의 데이터는 엿보는 눈으로부터 보호되어야 합니다. 이를 미사용 암호화라고 합니다. 기업은 민감한 데이터를 보호할 때 체인에 약한 링크가 없는지 확인해야 합니다.
액세스 데이터 기록 실패
5. 비활성화되거나 활성화되지 않거나 잘못 구성된 CloudTrail
Amazon CloudTrail은 AWS 사용자에게 계정에 대해 수행된 모든 API 호출의 전체 기록을 제공합니다. 여기에는 AWS Management 콘솔, SDK, 명령어(CLI) 도구 및 기타 AWS 서비스에서 이루어진 호출이 포함됩니다. CloudTrail은 이 데이터의 로그 파일을 생성하고 지정된 S3 버킷에 로그 파일을 저장합니다. 로그 파일에는 호출의 소스 IP 주소와 호출 날짜 및 시간이 포함됩니다.
관리자는 서비스 및 인스턴스 관리를 위해 AWS 계정에 액세스하는 사람과 위치를 항상 알 수 있도록 AWS 계정 내에서 CloudTrail을 활성화해야 합니다.
6. 모든 S3 버킷에 대한 로깅 활성화 하지 않음
로깅은 기본적으로 비활성화되어 있으므로 모든 S3 버킷에서 수동으로 활성화해야 합니다. 활성화하면 요청 유형, 요청에 사용된 리소스, 요청이 처리된 날짜 및 시간이 포함된 버킷에 대해 이루어진 모든 요청에 대한 액세스 로그 레코드가 생성됩니다.
CloudTrail과 마찬가지로 모든 S3 버킷에서 로깅을 활성화하는 것은 버킷에 대해 이루어진 요청의 특성에 대한 통찰력을 제공하므로 중요합니다. 이를 통해 관리자는 리소스가 많은 트래픽을 수신하고 있는지 여부를 결정할 수 있습니다. 즉, 실수로 공개된 리소스일 수 있습니다.
IP 주소 및 접근 제어 설정
7. VPC에 불충분한 IP 주소 범위
Virtual Private Cloud(VPC)는 VPN처럼 작동하므로 사용자가 격리된 가상 네트워크에서 AWS 리소스를 시작할 수 있습니다. 관리자는 필요한 보안 수준에 따라 IP 주소 범위를 선택하고 서브넷을 만들고 라우팅 테이블과 네트워크 게이트웨이를 구성하여 가상 사설 클라우드에 액세스할 수 있는 사람을 제어할 수 있습니다.
이것은 사용자 정의 가능한 솔루션이므로 클라우드 관리자는 가상 사설 클라우드 환경에서 권한을 정의해야 합니다. VPC에 대해 특정 IP 범위만 지정해야 하며 필요한 포트만 노출해야 합니다. VPC를 모든 포트와 모든 IP 주소에 개방된 상태로 두는 것은 악의적인 사용자에게 큰 공격 표면을 생성하므로 매우 권장하지 않습니다.
8. 데이터베이스 보안 그룹을 위한 광범위한 IP 범위 액세스
데이터베이스(DB) 보안 그룹은 인스턴스 그룹으로 허용되는 트래픽을 제어하는 방화벽 역할을 합니다. EC2 인스턴스에는 여러 보안 그룹이 할당될 수 있으며 보안 그룹에 대한 규칙은 언제든지 수정할 수 있습니다.
각 보안 그룹에는 할당된 인스턴스에 허용되는 인바운드 트래픽을 지시하는 규칙이 있습니다. 다른 모든 트래픽은 삭제됩니다. 이러한 규칙을 사용하면 특정 소스가 특정 프로토콜(TCP, UDP 또는 ICMP) 및 대상 포트를 사용하여 인스턴스에 액세스할 수 있습니다. 이 소스는 개별 IP 주소 또는 주소 범위일 수 있습니다. 인스턴스를 보호하려면 DB 보안 그룹에 대해 특정 IP 범위만 지정해야 합니다.
9. 네트워크 액세스 제어 목록은 모든 인바운드 트래픽을 허용하지 않습니다.
NACL(네트워크 액세스 제어 목록)은 서브넷 안팎의 트래픽을 제어하기 위한 방화벽 역할을 하는 선택적 보안 계층입니다. 관리자는 VPC에 보안 계층을 추가하기 위해 보안 그룹과 유사한 규칙으로 NACL을 설정할 수 있습니다.
NACL 내의 규칙은 규칙에 대해 설정된 규칙 번호를 기반으로 평가됩니다. AWS는 요청과 일치하는 첫 번째 규칙에 따라 패킷을 허용하거나 거부합니다. 일치시킬 가장 낮거나 첫 번째 번호가 지정된 규칙이 우선 적용되어 사용됩니다.
VPC의 default NACL은 모든 인바운드 포트와 IP 주소를 허용합니다. 그러므로 default NACL을 사용하면 안 됩니다.
모범 사례는 트래픽을 필요한 포트와 IP 주소로만 제한하는 것입니다. 관리자가 모든 포트와 IP 주소에 대해 열린 NACL을 찾으면 해당 규칙을 제거하고 적절한 인바운드 트래픽만 허용하는 보다 제한적인 규칙을 만들어야 합니다.
