기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # ADDF 보안 설정 및 운영 ADDF(Autonomous Driving Data Framework)는 조직의 전담 DevOps 및 보안 팀의 지속적 유지 보수와 관리가 필요한 맞춤형 소프트웨어로 취급되어야 합니다. 이 섹션에서는 수명 주기 전반에 걸쳐 ADDF를 설정하고 운영하는 데 도움이 되는 보안 관련 일반 작업을 설명합니다. 이 섹션에는 다음 태스크가 포함되어 있습니다. + [ADDF 아키텍처 정의](#defining-your-addf-architecture) + [초기 설정](#initial-setup) + [ADDF 배포 프레임워크 코드 사용자 지정](#customizing-the-addf-deployment-framework-code) + [ADDF에서 사용자 지정 모듈 작성](#writing-custom-modules-in-addf) + [반복되는 ADDF 배포](#reoccurring-addf-deployments) + [반복되는 보안 감사](#reoccurring-security-audits) + [ADDF 업데이트](#addf-updates) + [서비스 해제](#decommissioning) ## ADDF 아키텍처 정의 ADDF 인스턴스는 배포된 AWS 계정 환경만큼만 안전합니다. 이 AWS 계정 환경은 특정 사용 사례의 보안 및 운영 요구 사항을 충족하도록 설계되어야 합니다. 예를 들어, 개념 증명(PoC) 환경에서 ADDF 인스턴스를 설정하기 위한 보안 및 운영 관련 작업과 고려 사항은 프로덕션 환경에서 ADDF를 설정하는 경우와 다릅니다. ### PoC 환경에서 ADDF 실행 PoC 환경에서 ADDF를 사용하려는 경우 다른 워크로드가 포함되지 않은 ADDF AWS 계정 전용를 생성하는 것이 좋습니다. 이렇게 하면 ADDF와 해당 기능을 탐색하는 동안 계정을 안전하게 유지할 수 있습니다. 이 접근 방식은 다음과 같은 이점이 있습니다.  + 심각한 ADDF 구성 오류가 발생하더라도 다른 워크로드에 부정적인 영향이 없습니다. + ADDF 설정에 부정적인 영향을 줄 수 있는 다른 워크로드 구성 오류의 위험은 없습니다. PoC 환경의 경우에도 [프로덕션 환경에서 ADDF 실행](#running-addf-in-a-production-environment)에 나열된 모범 사례를 최대한 많이 따르는 것이 좋습니다. ### 프로덕션 환경에서 ADDF 실행 엔터프라이즈 프로덕션 환경에서 ADDF를 사용하려는 경우 조직의 보안 모범 사례를 고려하여 그에 따라 ADDF를 구현하는 것이 좋습니다. 조직의 보안 모범 사례 외에도 다음을 구현하는 것이 좋습니다. + **장기적이고 헌신적인 ADDF DevOps 팀 구성** – ADDF를 맞춤형 소프트웨어로 취급해야 합니다. 전담 DevOps 팀의 지속적 유지 보수 및 관리가 필요합니다. 프로덕션 환경에서 ADDF 실행을 시작하기 전에 ADDF 배포 수명이 끝날 때까지 전체 리소스를 투입하여 충분한 규모와 기능을 갖춘 DevOps 팀을 정의해야 합니다. + **다중 계정 아키텍처 사용 **– 관련 없는 다른 워크로드 없이 자체 전용 AWS 다중 계정 환경에 각 ADDF 인스턴스를 배포해야 합니다. [AWS 계정 관리 및 분리](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/aws-account-management-and-separation.html)(AWS Well-Architected Framework)에 정의된 대로 조직의 요구 사항에 AWS 계정따라 리소스와 워크로드를 여러 로 분리하는 것이 모범 사례로 간주됩니다. 이는가 격리 경계 AWS 계정 역할을 하기 때문입니다. 적절하게 설계된 AWS 다중 계정 아키텍처는 워크로드 분류를 제공하며 보안 침해 발생 시 단일 계정 아키텍처보다 영향 범위가 작습니다. 다중 계정 아키텍처를 사용하면 계정을 [AWS 서비스 할당량](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) 내로 유지할 수 있습니다 조직의 보안 및 업무 분리 요구 사항을 충족하는 데 필요한 만큼의 AWS 계정 에 ADDF 모듈을 배포합니다. + **여러 ADDF 인스턴스 배포** – 조직의 소프트웨어 개발 프로세스에 따라 ADDF 모듈을 적절히 개발, 테스트 및 배포하기 위해 필요한 만큼 별도의 ADDF 인스턴스를 설정합니다. 여러 ADDF 인스턴스를 설정할 때 다음 접근 방식 중 하나를 사용할 수 있습니다. + 서로 **다른 AWS 다중 계정 환경의 여러 ADDF 인스턴스 - **별도의를 사용하여 서로 다른 ADDF 인스턴스 AWS 계정 를 격리할 수 있습니다. 예를 들어, 조직에 전용 개발, 테스트 및 프로덕션 단계가 있는 경우 각 단계에 대해 별도의 ADDF 인스턴스와 전용 계정을 생성할 수 있습니다. 이렇게 하면 오류가 여러 단계로 전파될 위험이 줄고, 승인 프로세스를 구현하는 데 도움이 되고, 사용자 액세스가 특정 환경으로만 제한되는 등 많은 이점이 있습니다. 다음 이미지는 별도의 다중 계정 환경에 배포된 2개의 ADDF 인스턴스를 보여줍니다. ![다중 계정 아키텍처가 있는 별도의 AWS 환경에 있는 두 개의 ADDF 인스턴스](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/addf-security-and-operations/images/A_multi-addf-multi-account.png) + **동일한 AWS 다중 계정 환경의 여러 ADDF 인스턴스 - **동일한 AWS 다중 계정 환경을 공유하는 여러 ADDF 인스턴스를 생성할 수 있습니다. 이렇게 하면 동일한 AWS 계정에 격리된 브랜치가 효과적으로 생성됩니다. 예를 들어, 여러 개발자가 동시에 작업하는 경우 개발자는 동일한 AWS 계정에 전용 ADDF 인스턴스를 생성할 수 있습니다. 이를 통해 개발자는 개발 및 테스트 목적으로 격리된 브랜치에서 작업할 수 있습니다. 이 접근 방식을 사용하는 경우 각 ADDF 인스턴스마다 ADDF 리소스에 고유한 리소스 이름이 있어야 합니다. 이는 ADDF 사전 제공 모듈에서 기본적으로 지원됩니다. [AWS 서비스 할당량](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)을 초과하지 않는 한 이 접근 방식을 사용할 수 있습니다. 다음 이미지는 공유 다중 계정 환경에 배포된 2개의 ADDF 인스턴스를 보여줍니다. ![동일한 AWS 다중 계정 환경 위치에 배포된 2개의 ADDF 인스턴스](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/addf-security-and-operations/images/C_multi-instance-multi-account-shared.png) + **동일한 AWS 단일 계정 환경의 여러 ADDF 인스턴스** – 이 아키텍처는 이전 예와 매우 유사합니다. 차이점은 여러 ADDF 인스턴스가 다중 계정 환경 대신 단일 계정 환경에 배포된다는 것입니다. 이 아키텍처는 범위가 매우 제한적이고 여러 개발자가 동시에 여러 브랜치에서 작업하는 매우 간단한 ADDF 사용 사례에 적합합니다. ![동일한 AWS 단일 계정 환경 위치에 배포된 2개의 ADDF 인스턴스](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/addf-security-and-operations/images/B_multi-addf-single-account.png) SeedFarmer는 ADDF 인스턴스의 배포를 제어하는 단일 도구이므로 조직의 배포 전략 및 CI/CD 프로세스에 맞는 모든 환경과 계정 아키텍처를 구축할 수 있습니다. + **조직의 보안 요구 사항에 따라 AWS Cloud Development Kit (AWS CDK) 부트스트랩 프로세스 사용자 지정** - 기본적으로 부트스트랩 프로세스 중에 [AdministratorAccess](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html#jf_administrator) AWS 관리형 정책을 AWS CDK 할당합니다. 이 정책은 전체 관리 권한을 부여합니다. 이 정책이 조직의 보안 요구 사항에 비해 너무 허용적인 경우 적용되는 정책을 사용자 지정할 수 있습니다. 자세한 내용은 [AWS CDK 배포 역할에 대한 사용자 지정 최소 권한 정책](built-in-security-features.md#custom-least-privilege-policy-for-the-aws-cdk-deployment-role) 단원을 참조하십시오. + **IAM에서 액세스를 설정할 때 모범 사례 준수** - 사용자가 ADDF에 액세스할 수 있는 구조화된 AWS Identity and Access Management (IAM) 액세스 솔루션을 설정합니다 AWS 계정. ADDF의 프레임워크는 최소 권한 원칙을 준수하도록 설계되었습니다. IAM 액세스 패턴은 최소 권한 원칙을 따르고 조직의 요구 사항과 [IAM의 보안 모범 사례](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)(IAM 설명서)를 준수해야 합니다. + **조직의 모범 사례에 따라 네트워킹 설정** - ADDF에는 기본 퍼블릭 또는 프라이빗 Virtual Private Cloud(VPC)를 생성하는 선택적 네트워킹 AWS CloudFormation 스택이 포함되어 있습니다. 조직의 구성에 따라 이 VPC는 리소스를 인터넷에 직접 노출할 수 있습니다. 조직의 네트워킹 모범 사례를 따르고 보안이 강화된 사용자 지정 네트워크 모듈을 생성하는 것이 좋습니다. + **보안 예방, 탐지 및 완화 조치를 AWS 계정 수준에서 배포 **- AWS 는 Amazon GuardDuty, AWS Security Hub CSPM Amazon Detective 및와 같은 다양한 보안 서비스를 제공합니다 AWS Config. ADDF에서 이러한 서비스를 활성화 AWS 계정 하고 조직의 보안 예방, 탐지, 완화 및 인시던트 처리 프로세스를 통합합니다. [보안, 자격 증명 및 규정 준수 모범 사례](https://aws.amazon.com/architecture/security-identity-compliance/)(AWS 아키텍처 센터)와 해당 서비스의 설명서에 포함된 서비스별 권장 사항을 따르는 것이 좋습니다. 자세한 내용은 [AWS 보안 설명서](https://docs.aws.amazon.com/security/)를 참조하세요. 구현 및 구성 세부 정보는 조직의 특정 요구 사항 및 프로세스에 따라 크게 달라지기 때문에 ADDF에서는 이러한 주제를 다루지 않습니다. 대신 이러한 주제를 다루는 것이 조직의 핵심적인 책임입니다. 일반적으로 [AWS 랜딩 존](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-aws-environment/understanding-landing-zones.html)을 관리하는 팀은 ADDF 환경을 계획하고 구현하는 데 도움을 줍니다. ## 초기 설정 [ADDF Deployment Guide](https://github.com/awslabs/autonomous-driving-data-framework/blob/main/docs/deployment_guide.md)(GitHub)에 따라 ADDF를 설정합니다. 모든 배포의 시작점은 [autonomous-driving-data-framework](https://github.com/awslabs/autonomous-driving-data-framework) Git Hub 리포지토리의 `/manifest` 폴더입니다. `/manifest/example-dev` 폴더에는 데모용 샘플 배포가 포함되어 있습니다. 이 샘플을 자신의 배포를 설계하는 시작점으로 사용합니다. 해당 디렉터리에는 **deployment.yaml**이라는 ADDF 배포 매니페스트 파일이 있습니다. 여기에는 SeedFarmer가 AWS 클라우드에서 ADDF 및 해당 리소스를 관리, 배포 또는 삭제하는 데 필요한 모든 정보가 포함되어 있습니다. 전용 파일에 ADDF 모듈 그룹을 생성할 수 있습니다. **core-modules.yaml**은 코어 모듈 그룹의 한 예로 ADDF에서 제공하는 모든 코어 모듈을 포함합니다. 요약하면 **deployment.yaml** 파일은 대상 계정에 배포될 그룹과 모듈에 대한 모든 참조를 포함하며 배포 순서를 지정합니다. 특히 개념 증명을 위한 것이 아닌 환경에서는 안전하고 규정을 준수하는 구성의 경우 배포하려는 각 모듈의 소스 코드를 검토하는 것이 좋습니다. 보안 강화 모범 사례에 따르면 의도한 사용 사례에 필요한 모듈만 배포해야 합니다. **참고** `modules/demo-only/` 폴더의 ADDF 모듈은 보안이 강화되지 않았으므로 프로덕션 환경 또는 민감하거나 보호되는 데이터가 있는 환경에 배포해서는 안 됩니다. 이러한 모듈은 시스템 기능을 보여주기 위해 포함되어 있으며, 보안이 강화된 사용자 지정 자체 모듈을 생성하기 위한 기반으로 사용할 수 있습니다. ## ADDF 배포 프레임워크 코드 사용자 지정 ADDF 배포 프레임워크와 해당 오케스트레이션 및 배포 로직은 모든 요구 사항에 맞게 완전히 사용자 지정할 수 있습니다. 하지만 다음과 같은 이유로 사용자 지정을 삼가거나 변경 내용을 최소화하는 것이 좋습니다. + **업스트림 호환성 유지** - 업스트림 호환성으로 최신 기능 및 보안 업데이트를 위해 ADDF를 보다 쉽게 업데이트할 수 있습니다. 프레임워크를 변경하면 SeedFarmer, CodeSeeder 및 모든 ADDF 코어 모듈과의 기본 하위 버전 호환성이 중단됩니다. + **보안 결과** – ADDF 배포 프레임워크를 변경하는 것은 의도하지 않은 보안 결과를 초래할 수 있는 복잡한 작업일 수 있습니다. 최악의 시나리오에서는 프레임워크 변경으로 인해 보안이 취약해질 수 있습니다. 가능하면 ADDF 배포 프레임워크와 ADDF 코어 모듈 코드를 수정하는 대신 자체 모듈 코드를 빌드하고 사용자 지정합니다. **참고** ADDF 배포 프레임워크의 특정 부분에 개선이나 추가 보안 강화가 필요하다고 생각되면 풀 요청을 통해 ADDF 리포지토리에 변경 사항을 제공하세요. 자세한 내용은 [오픈 소스 보안 검토 및 기여](addf-security-review-process.md#open-source-sec-reviews) 단원을 참조하십시오. ## ADDF에서 사용자 지정 모듈 작성 새로운 ADDF 모듈을 생성하거나 기존 모듈을 확장하는 것이 ADDF의 핵심 개념입니다. 모듈을 생성하거나 사용자 지정할 때 일반적인 AWS 보안 모범 사례와 안전한 코딩을 위한 조직의 모범 사례를 따르는 것이 좋습니다. 또한 조직의 보안 요구 사항에 따라 초기 및 주기적인 내부 또는 외부 기술 보안 검토를 수행하여 보안 문제의 위험을 더욱 줄이는 것이 좋습니다. ## 반복되는 ADDF 배포 [ADDF Deployment Guide](https://github.com/awslabs/autonomous-driving-data-framework/blob/main/docs/deployment_guide.md)(GitHub)에 설명된 대로 ADDF와 해당 모듈을 배포합니다. 대상 계정에서 리소스를 추가, 업데이트 또는 제거하는 반복적인 ADDF 배포를 지원하기 위해 SeedFarmer는 도구 체인 및 대상 계정의 Parameter Store에 저장된 MD5 해시를 사용하여 현재 배포된 인프라를 로컬 코드 베이스의 매니페스트 파일에 정의된 인프라와 비교합니다. 이 접근 방식은 소스 리포지토리(SeedFarmer를 운영하는 로컬 코드 베이스)가 신뢰할 수 있는 소스이고 여기에 명시적으로 선언된 인프라가 배포에서 원하는 결과인 GitOps 패러다임을 따릅니다. GitOps에 대한 자세한 내용은 [What is GitOps](https://about.gitlab.com/topics/gitops/)(GitLab 웹 사이트)를 참조하세요. ## 반복되는 보안 감사 조직의 다른 소프트웨어와 마찬가지로 ADDF와 사용자 지정 ADDF 모듈 코드를 보안 위험 관리, 보안 검토 및 보안 감사 주기에 통합합니다. ## ADDF 업데이트 ADDF는 지속적인 개발 노력의 일환으로 정기적인 업데이트를 받습니다. 여기에는 기능 업데이트, 보안 관련 개선 및 수정이 포함됩니다. 정기적으로 새 프레임워크 릴리스를 확인하고 적시에 업데이트를 적용하는 것이 좋습니다. 자세한 내용은 [Steps to update ADDF](https://github.com/awslabs/autonomous-driving-data-framework/blob/main/docs/deployment_guide.md#steps-to-update-addf-deployment-when-there-is-a-new-change-from-addf-team-if-a-new-release-is-published)(ADDF 설명서)를 참조하세요. ## 서비스 해제 더 이상 필요 없는 경우 AWS 계정에서 ADDF와 모든 관련 리소스를 삭제합니다. 사용되지 않는 무인 인프라는 불필요한 비용과 잠재적인 보안 위험을 초래합니다. 자세한 내용은 [Steps to destroy ADDF](https://github.com/awslabs/autonomous-driving-data-framework/blob/main/docs/deployment_guide.md#steps-to-destroy-addf)(ADDF 설명서)를 참조하세요.