ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • Amazon AWS Certified SA - Professional 1~5번
    AWS 2023. 4. 20. 01:30

    1. 회사 정책에 따라 유휴 상태의 민감한 데이터를 암호화해야 합니다. EC2 인스턴스에 연결된 EBS 데이터 볼륨에 미사용 데이터를 저장하는 동안 데이터를 보호할 수 있는 옵션을 고려하고 있습니다.
    다음 중 미사용 데이터를 암호화할 수 있는 옵션은 무엇입니까? (세 가지를 선택하세요.)

    A. 타사 볼륨 암호화 도구 구현
    B. 서버에서 실행 중인 모든 서비스에 대해 SSL/TLS 구현
    C. EBS에 저장하기 전에 애플리케이션 내부의 데이터를 암호화합니다.
    D. 파일 시스템 수준에서 기본 데이터 암호화 드라이버를 사용하여 데이터 암호화
    E. EBS 볼륨은 기본적으로 암호화되어 있으므로 아무것도 하지 않음

     

    해설
    A. 타사 볼륨 암호화 도구 구현:
    타사 볼륨 암호화 도구를 사용하여 데이터를 암호화할 수 있습니다. 이러한 도구는 전체 볼륨을 암호화하고, 암호화 및 복호화 프로세스를 자동화하는 데 도움이 됩니다. 이 방식은 볼륨에 저장된 모든 데이터를 보호하는 데 효과적입니다. 다양한 타사 솔루션이 있으며, 회사의 요구 사항과 호환되는 도구를 선택해야 합니다.

    C. EBS에 저장하기 전에 애플리케이션 내부의 데이터를 암호화합니다:
    이 옵션에서는 애플리케이션 수준에서 데이터를 암호화합니다. 즉, 데이터가 EBS 볼륨에 저장되기 전에 애플리케이션 로직에 따라 암호화가 수행됩니다. 이 방식은 데이터가 볼륨에 기록되기 전에 암호화되므로, EBS에 저장된 데이터는 이미 암호화된 상태입니다.

    D. 파일 시스템 수준에서 기본 데이터 암호화 드라이버를 사용하여 데이터 암호화:
    파일 시스템 수준 암호화는 운영 체제 또는 파일 시스템에서 제공하는 암호화 기능을 사용하여 데이터를 암호화합니다. 이 방식은 각 파일이나 폴더에 대해 암호화를 적용할 수 있으며, 필요한 경우 암호화를 적용하지 않을 수도 있습니다. 일반적으로 이러한 암호화 기능은 운영 체제에 포함되어 있거나 추가적인 드라이버나 소프트웨어를 설치하여 사용할 수 있습니다.

    B. 서버에서 실행 중인 모든 서비스에 대해 SSL/TLS 구현: SSL/TLS는 보안 소켓 계층(Secure Socket Layer) 및 전송 계층 보안(Transport Layer Security)을 의미하며, 네트워크에서 데이터를 전송할 때 사용되는 암호화 프로토콜입니다. SSL/TLS는 주로 웹 서버와 클라이언트 간의 데이터 전송을 암호화하고, 제 3자가 데이터를 가로채거나 변조하는 것을 방지하는 데 사용됩니다. 이 방식은 데이터 전송 시에만 암호화되며, 저장된 데이터에 대한 암호화를 제공하지 않습니다. 따라서, 미사용 데이터의 암호화와 관련이 없습니다.

    E. EBS 볼륨은 기본적으로 암호화되어 있으므로 아무것도 하지 않음: 이 옵션은 EBS 볼륨이 기본적으로 암호화되어 있다고 가정하지만, 이는 사실이 아닙니다. 기본적으로 EBS 볼륨은 암호화되어 있지 않습니다. 암호화를 사용하려면, 볼륨을 생성할 때 명시적으로 암호화를 활성화해야 합니다. 따라서, 이 옵션은 미사용 데이터를 암호화하는 데 적합하지 않습니다.

    1. EBS란 무엇인가요?

    AWS EBS(Elastic Block Store)는 AWS 클라우드의 Amazon EC2 인스턴스에 사용할 영구 블록 스토리지 볼륨을 제공합니다. EBS는 EC2 인스턴스에서 디스크처럼 사용할 수 있는 '블록’수준 스토리지 하나의 인스턴스 또는 여러개 인스턴스에 동시에 연결할 수 있는 AWS의 외장하드디스크입니다. EBS는 다양한 타입을 지원하며, 네트워크 연결을 통해 인스턴스 간 연결 및 해제가 가능합니다.

    EBS는 EC2를 위한 비휘발성 Block Storage이고, SSD/HDD 등 다양한 타입을 지원합니다. EBS 볼륨 유형은 성능 특성과 가격이 다르므로 애플리케이션의 필요에 맞게 스토리지 성능과 비용을 조정할 수 있습니다.

    2. EBS와 S3의 차이점은 무엇인가요?

    EBS (Elastic Block Store) :

    블록 스토리지: EBS는 블록 레벨 스토리지로, 데이터를 블록 단위로 저장하고 관리합니다.
    EC2 인스턴스에 연결: EBS 볼륨은 AWS EC2 인스턴스에 연결되어 사용되며, 인스턴스와 함께 부팅되거나 추가 데이터 스토리지로 사용할 수 있습니다.
    낮은 지연 시간: EBS는 EC2 인스턴스와 가까운 위치에 저장되므로, 낮은 지연 시간을 제공합니다.
    데이터 내구성: EBS 볼륨의 데이터는 자동으로 복제되어 가용 영역(AZ) 내에서 내구성을 제공합니다.
    고성능: EBS는 IOPS-intensive, 특히 데이터베이스와 같은 응용 프로그램에 적합한 고성능 스토리지입니다.

    S3 (Simple Storage Service) :

    객체 스토리지: S3는 객체 기반 스토리지로, 데이터를 파일 형태의 객체로 저장하고 관리합니다.
    스탠드얼론 서비스: S3는 독립적인 스토리지 서비스로, EC2 인스턴스에 직접 연결되지 않습니다.
    높은 내구성 및 가용성: S3는 데이터를 여러 가용 영역(AZ)에 자동으로 복제하므로, 높은 내구성과 가용성을 제공합니다.
    웹 접근 가능: S3는 HTTP 및 HTTPS를 통해 웹에서 직접 접근할 수 있는 스토리지 서비스입니다.
    확장성: S3는 사용자가 필요에 따라 스토리지 용량을 무제한으로 확장할 수 있는 확장성을 제공합니다.

    결론적으로, EBS는 주로 EC2 인스턴스에 연결되어 사용되는 블록 레벨 스토리지로 성능이 중요한 애플리케이션에 적합하고, S3는 웹에서 접근 가능한 객체 기반 스토리지로 확장성과 내구성이 중요한 경우에 적합합니다.

    2. 고객이 AWS에 SSL 지원 웹 애플리케이션을 배포하고 있으며 인스턴스에 로그인하고 API 호출을 할 수 있는 EC2 서비스 관리자와 개인 키가 포함된 애플리케이션의 X.509 인증서를 유지 관리하고 독점적으로 액세스할 수 있는 보안 담당자 간에 역할 분리를 구현하고자 합니다.

    이 상황에서 고객은 SSL을 지원하는 웹 애플리케이션을 AWS 상에 배포하려고 합니다. 웹 애플리케이션은 EC2 서비스 관리자가 관리하고, 애플리케이션의 보안을 관리하는 보안 담당자가 있습니다. 이들 간의 역할 분리를 구현하려고 하는데, 이는 각 직원이 서로 다른 역할을 수행하며 서로의 작업 영역에 개입하지 않도록 하기 위함입니다. SSL 지원 웹 애플리케이션은 인터넷 상에서 데이터를 안전하게 전송하기 위해 SSL 인증서를 사용합니다. 여기서 X.509 인증서는 애플리케이션을 보호하기 위한 공개 키와 개인 키를 포함합니다. 이러한 인증서의 관리와 보안은 매우 중요합니다. 고객은 EC2 서비스 관리자가 인스턴스에 로그인하고 API 호출을 할 수 있게 하면서, 보안 담당자만이 애플리케이션의 X.509 인증서에 독점적으로 액세스할 수 있도록 역할을 나누려고 합니다. 이렇게 하면, 각 직원이 자신의 역할에만 집중할 수 있고, 민감한 보안 정보에 대한 무단 액세스를 방지할 수 있습니다.

    A. 보안 담당자가 소유하고 웹 서버의 EC2 역할만 액세스할 수 있는 S3 버킷에 인증서를 업로드합니다.
    B. 보안 담당자가 관리하는 CloudHSM에서 부팅 시 인증서를 검색하도록 웹 서버를 구성합니다.
    C. 인증서에 대한 액세스를 기관 보안 담당자로만 제한하도록 웹 서버의 시스템 권한을 구성합니다.
    D. 보안 담당자에게만 인증서 저장소에 대한 액세스를 승인하는 IAM 정책을 구성하고 ELB에서 SSL을 종료합니다.

     

    해설
    D. 보안 담당자에게만 인증서 저장소에 대한 액세스를 승인하는 IAM 정책을 구성하고 ELB에서 SSL을 종료합니다.

    이 옵션은 역할 분리를 구현하기에 적합한 선택입니다. IAM 정책을 사용하여 보안 담당자만이 인증서 저장소에 액세스할 수 있도록 설정할 수 있습니다. 또한, SSL 종료를 ELB (Elastic Load Balancer)에서 수행하면, 웹 서버에서 SSL을 처리할 필요가 없어지므로 EC2 서비스 관리자가 인증서에 액세스할 필요가 없습니다. 이렇게 하면 보안 담당자와 EC2 서비스 관리자 간의 역할 분리를 구현할 수 있습니다.

    A. 보안 담당자가 소유하고 웹 서버의 EC2 역할만 액세스할 수 있는 S3 버킷에 인증서를 업로드합니다.

    이 옵션에서는 SSL 인증서를 S3 버킷에 저장하고, 웹 서버의 EC2 역할만이 해당 버킷에 액세스할 수 있도록 제한합니다. 그러나 이렇게 설정하면 EC2 서비스 관리자도 인스턴스에 로그인할 때 해당 인증서에 액세스할 수 있게 되어 역할 분리를 완전하게 구현할 수 없습니다.

    B. 보안 담당자가 관리하는 CloudHSM에서 부팅 시 인증서를 검색하도록 웹 서버를 구성합니다.

    CloudHSM은 높은 수준의 보안을 제공하지만, 복잡한 설정 및 추가 비용이 필요합니다. 이 옵션은 역할 분리를 구현할 수 있지만, 보다 간단한 방법이 있으므로 비효율적입니다.

    C. 인증서에 대한 액세스를 기관 보안 담당자로만 제한하도록 웹 서버의 시스템 권한을 구성합니다.

    이 옵션은 웹 서버의 시스템 권한을 통해 인증서에 대한 액세스를 제한하려고 시도합니다. 그러나 EC2 서비스 관리자가 인스턴스에 로그인하고 API 호출을 할 수 있다면, 시스템 권한을 우회할 가능성이 있으므로 역할 분리를 완벽하게 보장할 수 없습니다.
     
    1. SSL은 왜 종료해야하며, ELB에서 수행한다는 것은 무슨 말인가요?

    SSL 종료는 SSL/TLS 인증서를 사용하여 암호화된 네트워크 트래픽의 암호를 해독하는 과정을 말합니다. SSL 종료는 일반적으로 서버 또는 로드 밸런서와 같은 중간 네트워크 기기에서 수행됩니다.

    ELB에서 SSL을 종료한다는 것은 Elastic Load Balancer에서 SSL/TLS 암호화를 해독하고, 그 후에 내부 네트워크에서 웹 서버와 통신하기 위해 일반적으로 암호화되지 않은 HTTP 트래픽으로 전환한다는 것입니다. 이렇게 하면 웹 서버에 부하가 줄어들고, SSL/TLS 인증서를 관리하기 쉬워집니다.

    SSL 종료를 ELB에서 수행하는 이유는 다음과 같습니다:

    중앙 집중식 인증서 관리: SSL 인증서를 로드 밸런서에서 관리하면 여러 웹 서버에서 인증서를 개별적으로 관리하는 것보다 더 간단하고 효율적입니다.
    성능 향상: SSL/TLS 암호 해독 작업은 처리 리소스가 많이 필요합니다. ELB에서 SSL 종료를 수행하면 웹 서버의 부하가 줄어들어 성능이 향상됩니다.
    보안 강화: SSL 종료를 ELB에서 수행하면, 웹 서버에 직접 SSL 인증서를 저장할 필요가 없습니다. 이렇게 하면 인증서에 대한 무단 액세스를 방지하고 보안을 강화할 수 있습니다.
    개인 정보 보호: SSL 종료를 사용하면 클라이언트와 로드 밸런서 간의 데이터 전송은 암호화되므로 외부 공격자로부터 데이터가 보호됩니다.

    3. 최근 도심 지역의 거리 소음과 공기질을 측정하기 위한 센서를 만드는 스타트업 회사에 입사했습니다. 이 회사는 3개월 동안 약 100개의 센서를 파일럿으로 배포하여 각 센서가 AWS에서 호스팅되는 백엔드에 매분 1KB의 센서 데이터를 업로드하고 있습니다. 파일럿 기간 동안 데이터베이스에서 피크 또는 10 IOPS를 측정했으며, 데이터베이스에 월 평균 3GB의 센서 데이터를 저장했습니다. 현재 배포는 EC2 인스턴스를 사용하는 부하 분산 자동 확장 수집 레이어와 500GB 표준 스토리지가 포함된 PostgreSQL RDS 데이터베이스로 구성되어 있습니다.
    파일럿은 성공적이라고 간주되며 CEO가 관심을 끌거나 잠재적인 투자자를 확보했습니다. 비즈니스 계획에는 백엔드에서 지원해야 하는 최소 10만 개의 센서 배포가 필요합니다. 또한 연도별 비교를 위해 최소 2년 동안 센서 데이터를 저장해야 합니다.개선. 자금을 확보하려면 플랫폼이 이러한 요구 사항을 충족하고 추가 확장을 위한 여지가 있는지 확인해야 합니다.
    어떤 설정이 요구 사항을 충족하나요?

    이 상황은 스타트업 회사가 도심 지역의 거리 소음과 공기질을 측정하는 센서를 개발하고 있습니다. 회사는 초기 테스트를 통해 성공적인 파일럿 프로젝트를 수행했으며, 이제 비즈니스를 확장하려고 합니다. 확장 계획에는 백엔드 시스템이 10만 개의 센서를 지원해야 하며, 센서 데이터를 최소 2년 동안 저장해야 합니다. 현재 시스템은 AWS의 EC2 인스턴스를 사용하여 부하 분산 및 자동 확장 수집 레이어와 함께 500GB 표준 스토리지가 포함된 PostgreSQL RDS 데이터베이스로 구성되어 있습니다. 이 구성은 파일럿 프로젝트를 지원하기 위해 사용되었지만, 이제 회사는 시스템을 업그레이드하고 확장성을 평가하여 더 많은 센서를 지원하고 장기적으로 데이터를 저장할 수 있는지 확인해야 합니다. 이를 위해 적절한 설정을 결정하고 적용해야 합니다.


    A. 수집 계층에 SQS 큐를 추가하여 RDS 인스턴스에 대한 쓰기를 버퍼링합니다.
    B. DynamoDB 테이블로 데이터를 수집하고 이전 데이터를 Redshift 클러스터로 이동합니다.
    C. RDS 인스턴스를 96TB의 스토리지를 갖춘 6노드 Redshift 클러스터로 교체합니다.
    D. 현재 아키텍처를 유지하되 RDS 스토리지를 3TB 및 10K 프로비저닝된 IOPS로 업그레이드합니다.

     

    해설
    B. DynamoDB 테이블로 데이터를 수집하고 이전 데이터를 Redshift 클러스터로 이동합니다.

    이 옵션은 요구 사항을 충족합니다. DynamoDB는 높은 IOPS와 확장성을 제공하므로 10만 개의 센서를 지원할 수 있습니다. 이후 데이터를 Redshift 클러스터로 이동하면 데이터 저장 및 분석을 위해 최소 2년 동안 센서 데이터를 유지할 수 있습니다. Redshift는 대규모 데이터 웨어하우스로 확장성이 뛰어나며 연도별 비교 및 분석에 적합합니다. 이 구성을 사용하면 회사는 현재 요구 사항을 충족하면서 추가 확장을 위한 여지도 확보할 수 있습니다.

    A. 수집 계층에 SQS 큐를 추가하여 RDS 인스턴스에 대한 쓰기를 버퍼링합니다.

    이 옵션은 RDS 인스턴스에 대한 쓰기 부하를 줄이는 데 도움이 되지만, 10만 개의 센서를 지원하거나 2년 동안 데이터를 저장하는 데 필요한 확장성을 제공하지는 않습니다. 또한, 데이터베이스 스토리지 용량을 업그레이드하지 않으므로, 이 설정만으로는 요구 사항을 충족할 수 없습니다.

    C. RDS 인스턴스를 96TB의 스토리지를 갖춘 6노드 Redshift 클러스터로 교체합니다.

    이 옵션은 데이터 저장에 대한 확장성을 제공하지만, Redshift는 데이터 웨어하우스로 설계되었으며 고성능 OLTP 시스템에 적합하지 않습니다. 센서 데이터를 실시간으로 수집하고 처리해야 하는 상황에서 Redshift로 전환하는 것은 적절한 해결책이 아닙니다.

    D. 현재 아키텍처를 유지하되 RDS 스토리지를 3TB 및 10K 프로비저닝된 IOPS로 업그레이드합니다.

    이 옵션은 스토리지 용량과 IOPS를 증가시키지만, 10만 개의 센서를 지원하기에는 여전히 부족할 수 있습니다. 또한, 이 설정은 데이터를 최소 2년 동안 저장할 수 있는지 확인하기 어렵습니다. 스토리지 용량이 3TB로 제한되어 있으며, 시간이 지남에 따라 데이터가 빠르게 증가할 것으로 예상되기 때문입니다. 이러한 이유로 이 옵션은 요구 사항을 완전히 충족하지 못합니다.
    1. Redshift란 무엇인가요?

    AWS Redshift는 클라우드 기반 데이터 웨어하우스 서비스입니다. 데이터 웨어하우스는 대규모 데이터를 저장하고 분석하는 데 사용되는 데이터베이스입니다. Redshift는 대규모 데이터를 처리하고 분석하기 위해 설계되었으며, 빠른 쿼리 성능과 확장성을 제공합니다.

     

    4. 한 웹 회사가 배포된 VPC에 침입 탐지 및 방지 시스템을 구현하려고 합니다. 이 플랫폼은 VPC 내부에서 실행되는 수천 개의 인스턴스로 확장할 수 있어야 합니다.
    이러한 목표를 달성하려면 솔루션을 어떻게 설계해야 할까요?


    A. 모니터링 소프트웨어와 무차별 모드 패킷 스니핑으로 설정된 탄력적 네트워크 인터페이스(ENI)로 인스턴스를 구성하여 VPC 전반의 트래픽을 확인합니다.


    B. 두 번째 VPC를 생성하고 기본 애플리케이션 VPC의 모든 트래픽을 확장 가능한 가상화된 IDS/IPS 플랫폼이 상주하는 두 번째 VPC로 라우팅합니다.


    C. 호스트 기반 'route' 명령을 사용하여 VPC에서 실행 중인 서버를 구성하여 플랫폼을 통해 모든 트래픽을 확장형 가상화 IDS/IPS로 보내도록 합니다.


    D. 모든 네트워크 트래픽을 수집하고 검사를 위해 해당 트래픽을 IDS/IPS 플랫폼으로 보내는 에이전트로 각 호스트를 구성합니다.

    해설
    B. 두 번째 VPC를 생성하고 기본 애플리케이션 VPC의 모든 트래픽을 확장 가능한 가상화된 IDS/IPS 플랫폼이 상주하는 두 번째 VPC로 라우팅합니다.

    이 옵션은 배포된 VPC에 대한 침입 탐지 및 방지 시스템을 구현하기 위한 확장 가능한 중앙 집중식 접근 방식을 제공합니다. 두 번째 VPC를 생성하고 기본 애플리케이션 VPC의 모든 트래픽을 이를 통해 라우팅하면 IDS/IPS 플랫폼이 상주하는 전용 환경을 구축할 수 있습니다. 이렇게 하면 기본 애플리케이션 VPC와 분리되어 IDS/IPS 시스템을 더 잘 관리하고 확장할 수 있습니다. 이렇게 하면 기본 VPC 내부에서 실행되는 수천 개의 인스턴스에서 발생하는 트래픽을 처리하도록 시스템을 효율적으로 확장할 수 있습니다.

    옵션 A
     
    A 옵션은 인스턴스에 모니터링 소프트웨어를 설치하고 탄력적 네트워크 인터페이스(ENI)를 무차별 모드 패킷 스니핑으로 설정
    하여 VPC 전반의 트래픽을 확인하도록 구성하는 것입니다. 하지만 AWS에서는 무차별 모드가 지원되지 않습니다. 따라서 이 옵션은 AWS 환경에서 구현할 수 없습니다.

    옵션 C

     C 옵션은 VPC에서 실행 중인 서버를 호스트 기반 'route' 명령을 사용하여 구성하고, 플랫폼을 통해 모든 트래픽을 확장 가능한 가상화 IDS/IPS로 보내도록 하는 것입니다. 하지만 이 방식은 트래픽이 호스트에 도달하기 전에 IDS/IPS 시스템을 거치지 않기 때문에 침입 예방 기능(IPS)을 충족하지 못합니다. 또한 수천 개의 인스턴스에 대한 호스트 기반 라우팅을 관리하는 것은 매우 복잡하고 확장성이 떨어집니다.

    옵션 D

     D 옵션은 각 호스트에 에이전트를 설치하여 모든 네트워크 트래픽을 수집하고 IDS/IPS 플랫폼으로 보내 검사하는 것입니다. 이 방식은 호스트별로 트래픽을 수집하고 분석할 수 있지만, 확장성과 중앙 집중화된 관리 측면에서 제한적입니다. 또한 이 구성은 침입 예방 시스템(IPS) 요구 사항을 충족하지 못합니다. 트래픽이 호스트에 도달하기 전에 IDS/IPS 시스템을 거쳐야 하는데, 이 옵션에서는 그렇지 않습니다.


    1. IDS/IPS 플랫폼 무엇인가요?

    IDS(침입 탐지 시스템)와 IPS(침입 방지 시스템)는 네트워크 보안에 있어 중요한 역할을 하는 시스템입니다. IDS/IPS 플랫폼은 네트워크 환경에서 발생하는 다양한 종류의 침입 시도와 위협을 탐지하고, 그에 적절하게 대응하는 기능을 제공하는 소프트웨어 및 하드웨어 기반의 솔루션을 말합니다.

    IDS(침입 탐지 시스템): IDS는 네트워크 트래픽을 모니터링하고, 악성 트래픽이나 의심스러운 활동을 탐지하여 관리자에게 알리는 역할을 합니다. IDS는 주로 두 가지 종류가 있습니다.

    - NIDS(Network-based Intrusion Detection System): 네트워크 기반 침입 탐지 시스템은 네트워크 전반의 트래픽을 모니터링하며, 악성 트래픽이나 공격 시도를 실시간으로 감지합니다.
    - HIDS(Host-based Intrusion Detection System): 호스트 기반 침입 탐지 시스템은 개별 호스트의 시스템 로그, 응용 프로그램 로그, 사용자 활동 등을 모니터링하여 침입을 탐지합니다.

    IPS(침입 방지 시스템): IPS는 IDS의 확장된 버전으로, 침입을 탐지할 뿐만 아니라 실시간으로 해당 위협을 차단하거나 대응하는 역할을 수행합니다. 이 시스템은 네트워크 트래픽을 감시하고 공격이 발생할 때 즉각적으로 대응하며, 정책에 따라 트래픽을 차단하거나 경고를 발송할 수 있습니다.

    2. 모드 패킷 스니핑와 탄력적 네트워크 인터페이스(ENI)란?

    모드 패킷 스니핑(packet sniffing)은 네트워크 트래픽을 캡처하고 분석하는 기술입니다. 패킷 스니퍼는 네트워크상에서 패킷(데이터 조각)을 수집하여 정보를 분석할 수 있습니다. 무차별 모드(promiscuous mode) 패킷 스니핑은 네트워크 카드가 모든 패킷을 수신하도록 설정되어 있어, 관련되지 않은 트래픽까지도 수집할 수 있는 방식입니다.

    탄력적 네트워크 인터페이스(ENI, Elastic Network Interface)는 Amazon Web Services(AWS)에서 제공하는 가상 네트워크 인터페이스입니다. ENI는 Amazon EC2 인스턴스에 연결되어 네트워크 연결을 제공하며, 각 ENI는 고유한 MAC 주소, 프라이빗 IP 주소, 퍼블릭 IP 주소 및 기타 네트워크 관련 설정을 포함할 수 있습니다. 이를 통해 사용자는 네트워크 구성을 더욱 유연하게 관리할 수 있습니다. 하지만, AWS에서는 무차별 모드로 ENI를 설정하는 것을 지원하지 않습니다.

    3. AWS가 무차별모드를 지원하지 않는 이유는?

    AWS에서 무차별 모드(promiscuous mode)를 지원하지 않는 주된 이유는 보안과 관련이 있습니다. 무차별 모드를 사용하면, 네트워크 카드가 네트워크상의 모든 패킷을 수신하게 됩니다. 이는 해당 네트워크에 있는 다른 사용자들의 트래픽도 수집할 수 있다는 것을 의미하며, 이로 인해 개인 정보 누출, 트래픽 조작 등의 보안 문제가 발생할 수 있습니다.

    AWS는 고객의 데이터 보안과 프라이버시를 최우선으로 고려하기 때문에, 이러한 보안 위험을 최소화하기 위해 무차별 모드를 지원하지 않습니다. 대신, AWS는 VPC Flow Logs, VPC Traffic Mirroring 등의 다른 네트워크 모니터링 및 분석 기능을 제공하여 사용자들이 안전하게 네트워크 트래픽을 모니터링하고 분석할 수 있도록 지원합니다.

    4. 트래픽이 호스트에 도달하기 전에 IDS/IPS 시스템을 거쳐야 하는 이유는?

    침입 탐지 및 침입 방지 시스템이 네트워크 내의 악성 행위를 감지하고 차단할 수 있도록 설계되었기 때문입니다.

    IDS(Intrusion Detection System)는 네트워크 트래픽을 모니터링하여 악의적인 행위나 정책 위반을 탐지하는 역할을 합니다. IPS(Intrusion Prevention System)는 IDS와 비슷한 기능을 수행하지만, 추가로 악의적인 행위를 실시간으로 차단하여 네트워크와 시스템을 보호하는 역할을 합니다.

    트래픽이 호스트에 도달하기 전에 IDS/IPS 시스템을 거친다면, 시스템은 트래픽에 포함된 악성 패킷을 검사하고 차단할 수 있습니다. 그러나 트래픽이 호스트에 먼저 도달한 후에만 IDS/IPS 시스템을 거치게 되면, 이미 악성 행위가 발생한 후에 이를 감지하고 차단하게 됩니다. 이렇게 되면 호스트에 이미 침입이 발생하거나 공격이 진행 중일 수 있어, 시스템의 전체적인 보안이 약화됩니다.

    따라서 트래픽이 호스트에 도달하기 전에 IDS/IPS 시스템을 거쳐야 침입 방지 기능(IPS)이 효과적으로 작동하며, 이를 통해 시스템을 안전하게 유지할 수 있습니다.

    5. 호스트에 에이전트를 설치한다는 것은 무엇인가요?

    호스트에 에이전트를 설치한다는 것은 컴퓨터나 서버(호스트)에 특정 소프트웨어를 설치하여 네트워크 트래픽을 수집하고 IDS/IPS 시스템으로 전송하는 역할을 수행하는 프로그램을 의미합니다. 에이전트는 호스트의 네트워크 상태를 실시간으로 모니터링하고, 이상 징후나 위협을 감지할 수 있게 도와줍니다.

    6. 확장성과 중앙 집중화된 관리가 왜 필요한 건가요?

    - 확장성: 시스템이 사용자 요구에 따라 쉽게 확장할 수 있어야 합니다. 예를 들어, 네트워크의 크기가 증가하거나 트래픽이 급증할 때, IDS/IPS 시스템이 이를 감당할 수 있는지 확인해야 합니다. 호스트별로 에이전트를 사용하면 호스트 수에 따라 관리가 복잡해지고 효율성이 떨어집니다.

    - 중앙 집중화된 관리: 여러 호스트에서 발생하는 네트워크 이벤트와 위협을 한 곳에서 효과적으로 관리하고 대응할 수 있어야 합니다. 이를 통해 보안 운영 효율성을 높이고, 대응 시간을 단축할 수 있습니다.

    7. 옵션 D가 IPS요구 사항을 충족하지 못하는 이유는?

    트래픽이 호스트에 도달하기 전에 IDS/IPS 시스템을 거치지 않기 때문입니다. 침입 예방 시스템(IPS)은 트래픽이 목적지 호스트에 도달하기 전에 악성 패킷을 차단해야 효과적으로 작동합니다. 그러나 D 옵션에서는 트래픽이 호스트에서 수집되고, 그 후에 IDS/IPS 시스템으로 전송되므로, 이미 침입이 발생한 후에 이를 감지하게 됩니다. 이로 인해 IPS 기능이 제대로 작동하지 않고, 시스템의 전체적인 보안 수준이 약화됩니다.

    8. B 옵션에서 첫 번째 VPC는 IDS/IPS 기능이 없는 건가요?

    첫 번째 VPC는 주로 애플리케이션 및 워크로드를 호스팅하고 실행하는 데 사용됩니다. 그리고 두 번째 VPC에 확장 가능한 가상화된 IDS/IPS 플랫폼을 배치하여, 첫 번째 VPC에서 발생하는 트래픽을 검사하고 보호하는 역할을 수행합니다. 이렇게 하면 트래픽이 목적지 호스트에 도달하기 전에 IDS/IPS 시스템을 거쳐 악성 패킷이 차단되며, 보안 요구 사항을 충족할 수 있습니다.

    5. 한 회사가 Amazon Simple Storage Service(S3)에 데이터를 저장하고 있습니다. 회사의 보안 정책에 따라 데이터를 미사용 시 암호화해야 합니다.다음 중 이를 달성할 수 있는 방법은 무엇인가요? (세 가지를 선택하세요.)

    A. AWS 키 관리 서비스 관리 키를 사용하여 Amazon S3 서버 측 암호화를 사용합니다.
    B. 고객이 제공한 키로 Amazon S3 서버 측 암호화를 사용합니다.
    C. EC2 키 쌍과 함께 Amazon S3 서버 측 암호화를 사용합니다.
    D. Amazon S3 버킷 정책을 사용하여 미사용 데이터에 대한 액세스를 제한합니다.
    E. 자체 마스터 키를 사용하여 Amazon S3로 수집하기 전에 클라이언트 측에서 데이터를 암호화합니다.
    F. Amazon S3로 전송하는 동안 SSL을 사용하여 데이터를 암호화합니다.

     

    해설
    A. AWS 키 관리 서비스 관리 키를 사용하여 Amazon S3 서버 측 암호화를 사용합니다.
    Amazon S3 서버 측 암호화를 사용하면 S3에서 객체를 저장할 때 자동으로 암호화됩니다. AWS 키 관리 서비스(KMS) 관리 키를 사용하면 AWS에서 키를 관리하고 저장합니다.

    B. 고객이 제공한 키로 Amazon S3 서버 측 암호화를 사용합니다.
    이 옵션에서 고객은 자신의 키를 제공하여 Amazon S3 서버 측 암호화를 사용할 수 있습니다. 이 방법은 고객이 키 관리에 대한 더 많은 통제력을 원할 때 사용됩니다.

    E. 자체 마스터 키를 사용하여 Amazon S3로 수집하기 전에 클라이언트 측에서 데이터를 암호화합니다.
    클라이언트 측 암호화를 사용하면 데이터가 Amazon S3에 업로드되기 전에 클라이언트에서 암호화됩니다. 이 방법은 데이터를 전송하기 전에 암호화하고 전송 후 복호화하는 데 사용됩니다. 고객은 자체 마스터 키를 사용하여 암호화 프로세스를 관리할 수 있습니다.

    C, D, F 옵션은 미사용 데이터를 암호화하는 데 적합하지 않습니다. C 옵션의 EC2 키 쌍은 인스턴스에 대한 액세스를 제어하는 데 사용되며, D 옵션의 Amazon S3 버킷 정책은 액세스 권한을 제한하는 데 사용됩니다. F 옵션의 SSL은 데이터 전송 중에만 암호화되며, 저장된 데이터는 암호화되지 않습니다.

    C. EC2 키 쌍과 함께 Amazon S3 서버 측 암호화를 사용합니다.
    EC2 키 쌍은 Amazon EC2 인스턴스에 대한 액세스를 제어하는 데 사용됩니다. 이 키 쌍은 인스턴스를 시작할 때 생성되며, 인스턴스에 로그인할 때 사용되는 공개 키와 개인 키로 구성됩니다. Amazon S3에서 데이터를 암호화하는 데 EC2 키 쌍을 사용하는 것은 적합하지 않으며, 두 서비스 간의 암호화 목적이 다릅니다.

    D. Amazon S3 버킷 정책을 사용하여 미사용 데이터에 대한 액세스를 제한합니다.
    Amazon S3 버킷 정책은 Amazon S3 버킷의 리소스에 대한 액세스 권한을 관리하는 데 사용됩니다. 정책은 JSON 형식으로 작성되며, 특정 사용자, 그룹 또는 IP 주소에 대한 액세스 권한을 부여하거나 거부할 수 있습니다. 버킷 정책은 데이터의 액세스를 제어하는 데 사용되지만, 데이터 자체를 암호화하지는 않습니다.

    F. Amazon S3로 전송하는 동안 SSL을 사용하여 데이터를 암호화합니다.
    SSL(Secure Sockets Layer)은 데이터를 클라이언트와 서버 간에 전송하는 동안 암호화하는 프로토콜입니다. SSL을 사용하면 전송 중인 데이터가 중간자 공격으로부터 보호됩니다. 그러나 SSL은 전송 중에만 데이터를 암호화하며, 데이터가 Amazon S3에 저장된 후에는 암호화되지 않습니다. 따라서 이 옵션은 미사용 데이터를 암호화하는 데 적합하지 않습니다.

     

    'AWS' 카테고리의 다른 글

    Amazon AWS Certified Cloud Practitioner 1~5번  (0) 2023.04.11
    Amazon AWS Certified SA - Associate 1~5번  (0) 2023.04.06
Designed by Tistory.