기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
ADDF 보안 설정 및 운영
ADDF(Autonomous Driving Data Framework)는 조직의 전담 DevOps 및 보안 팀의 지속적 유지 보수와 관리가 필요한 맞춤형 소프트웨어로 취급되어야 합니다. 이 섹션에서는 수명 주기 전반에 걸쳐 ADDF를 설정하고 운영하는 데 도움이 되는 보안 관련 일반 작업을 설명합니다.
이 섹션에는 다음 태스크가 포함되어 있습니다.
ADDF 아키텍처 정의
ADDF 인스턴스는 배포된 AWS 계정 계정 환경만큼 안전합니다. 이 AWS 계정 계정 환경은 특정 사용 사례의 보안 및 운영 요구 사항을 충족하도록 설계되어야 합니다. 예를 들어, 개념 증명(PoC) 환경에서 ADDF 인스턴스를 설정하기 위한 보안 및 운영 관련 작업과 고려 사항은 프로덕션 환경에서 ADDF를 설정하는 경우와 다릅니다.
PoC 환경에서 ADDF 실행
PoC 환경에서 ADDF를 사용하려는 경우 다른 워크로드가 포함되지 않은 ADDF 전용 AWS 계정을 생성하는 것이 좋습니다. 이렇게 하면 ADDF와 해당 기능을 탐색하는 동안 계정을 안전하게 유지할 수 있습니다. 이 접근 방식은 다음과 같은 이점이 있습니다.
-
심각한 ADDF 구성 오류가 발생하더라도 다른 워크로드에 부정적인 영향이 없습니다.
-
ADDF 설정에 부정적인 영향을 줄 수 있는 다른 워크로드 구성 오류의 위험은 없습니다.
PoC 환경의 경우에도 프로덕션 환경에서 ADDF 실행에 나열된 모범 사례를 최대한 많이 따르는 것이 좋습니다.
프로덕션 환경에서 ADDF 실행
엔터프라이즈 프로덕션 환경에서 ADDF를 사용하려는 경우 조직의 보안 모범 사례를 고려하여 그에 따라 ADDF를 구현하는 것이 좋습니다. 조직의 보안 모범 사례 외에도 다음을 구현하는 것이 좋습니다.
-
장기적이고 헌신적인 ADDF DevOps 팀 구성 – ADDF를 맞춤형 소프트웨어로 취급해야 합니다. 전담 DevOps 팀의 지속적 유지 보수 및 관리가 필요합니다. 프로덕션 환경에서 ADDF 실행을 시작하기 전에 ADDF 배포 수명이 끝날 때까지 전체 리소스를 투입하여 충분한 규모와 기능을 갖춘 DevOps 팀을 정의해야 합니다.
-
다중 계정 아키텍처 사용 – 관련 없는 다른 워크로드 없이 자체 전용 AWS 다중 계정 환경에 각 ADDF 인스턴스를 배포해야 합니다. AWS 계정 관리 및 분리(AWS Well-Architected Framework)에 정의된 대로 조직의 요구 사항에 따라 리소스와 워크로드를 여러 AWS 계정으로 분리하는 것이 가장 좋습니다. 이는 AWS 계정이 격리 경계 역할을 하기 때문입니다. 적절하게 설계된 AWS 다중 계정 아키텍처는 워크로드 분류를 제공하며 보안 침해 발생 시 단일 계정 아키텍처보다 영향 범위가 작습니다. 다중 계정 아키텍처를 사용하면 계정을 AWS 서비스 할당량 내로 유지할 수 있습니다 조직의 보안 및 업무 분리 요구 사항을 충족하는 데 필요한 만큼의 AWS 계정에 ADDF 모듈을 배포합니다.
-
여러 ADDF 인스턴스 배포 – 조직의 소프트웨어 개발 프로세스에 따라 ADDF 모듈을 적절히 개발, 테스트 및 배포하기 위해 필요한 만큼 별도의 ADDF 인스턴스를 설정합니다. 여러 ADDF 인스턴스를 설정할 때 다음 접근 방식 중 하나를 사용할 수 있습니다.
-
서로 다른 AWS 다중 계정 환경의 여러 ADDF 인스턴스 – 별도의 AWS 계정을 사용하여 서로 다른 ADDF 인스턴스를 격리할 수 있습니다. 예를 들어, 조직에 전용 개발, 테스트 및 프로덕션 단계가 있는 경우 각 단계에 대해 별도의 ADDF 인스턴스와 전용 계정을 생성할 수 있습니다. 이렇게 하면 오류가 여러 단계로 전파될 위험이 줄고, 승인 프로세스를 구현하는 데 도움이 되고, 사용자 액세스가 특정 환경으로만 제한되는 등 많은 이점이 있습니다. 다음 이미지는 별도의 다중 계정 환경에 배포된 2개의 ADDF 인스턴스를 보여줍니다.
-
동일한 AWS 다중 계정 환경의 여러 ADDF 인스턴스 – 동일한 AWS 다중 계정 환경을 공유하는 여러 ADDF 인스턴스를 생성할 수 있습니다. 이렇게 하면 동일한 AWS 계정에 격리된 브랜치가 효과적으로 생성됩니다. 예를 들어, 여러 개발자가 동시에 작업하는 경우 개발자는 동일한 AWS 계정에 전용 ADDF 인스턴스를 생성할 수 있습니다. 이를 통해 개발자는 개발 및 테스트 목적으로 격리된 브랜치에서 작업할 수 있습니다. 이 접근 방식을 사용하는 경우 각 ADDF 인스턴스마다 ADDF 리소스에 고유한 리소스 이름이 있어야 합니다. 이는 ADDF 사전 제공 모듈에서 기본적으로 지원됩니다. AWS 서비스 할당량을 초과하지 않는 한 이 접근 방식을 사용할 수 있습니다. 다음 이미지는 공유 다중 계정 환경에 배포된 2개의 ADDF 인스턴스를 보여줍니다.
-
동일한 AWS 단일 계정 환경의 여러 ADDF 인스턴스 – 이 아키텍처는 이전 예와 매우 유사합니다. 차이점은 여러 ADDF 인스턴스가 다중 계정 환경 대신 단일 계정 환경에 배포된다는 것입니다. 이 아키텍처는 범위가 매우 제한적이고 여러 개발자가 동시에 여러 브랜치에서 작업하는 매우 간단한 ADDF 사용 사례에 적합합니다.
SeedFarmer는 ADDF 인스턴스의 배포를 제어하는 단일 도구이므로 조직의 배포 전략 및 CI/CD 프로세스에 맞는 모든 환경과 계정 아키텍처를 구축할 수 있습니다.
-
-
조직의 보안 요구 사항에 따라 AWS Cloud Development Kit (AWS CDK) 부트스트랩 프로세스 사용자 지정 – 기본적으로 AWS CDK는 부트스트랩 프로세스 중에 AdministratorAccess AWS 관리형 정책을 할당합니다. 이 정책은 전체 관리 권한을 부여합니다. 이 정책이 조직의 보안 요구 사항에 비해 너무 허용적인 경우 적용되는 정책을 사용자 지정할 수 있습니다. 자세한 내용은 AWS CDK 배포 역할에 대한 사용자 지정 최소 권한 정책 섹션을 참조하세요.
-
IAM에서 액세스를 설정할 때 모범 사례 준수 – 사용자가 ADDFA AWS 계정에 액세스할 수 있도록 구조화된 AWS Identity and Access Management(IAM) 액세스 솔루션을 설정합니다. ADDF의 프레임워크는 최소 권한 원칙을 준수하도록 설계되었습니다. IAM 액세스 패턴은 최소 권한 원칙을 따르고 조직의 요구 사항과 IAM의 보안 모범 사례(IAM 설명서)를 준수해야 합니다.
-
조직의 모범 사례에 따라 네트워킹 설정 - ADDF에는 기본 퍼블릭 또는 프라이빗 Virtual Private Cloud(VPC)를 생성하는 선택적 네트워킹 AWS CloudFormation 스택이 포함되어 있습니다. 조직의 구성에 따라 이 VPC는 리소스를 인터넷에 직접 노출할 수 있습니다. 조직의 네트워킹 모범 사례를 따르고 보안이 강화된 사용자 지정 네트워크 모듈을 생성하는 것이 좋습니다.
-
AWS 계정 수준에서 보안 방지, 탐지 및 완화 조치 배포 – AWS는 Amazon GuardDuty, AWS Security Hub, Amazon Detective, AWS Config 등의 다양한 보안 서비스를 제공합니다. ADDF AWS 계정에서 이러한 서비스를 활성화하고 조직의 보안 예방, 탐지, 완화 및 사고 처리 프로세스를 통합합니다. 보안, 자격 증명 및 규정 준수 모범 사례
(AWS 아키텍처 센터)와 해당 서비스의 설명서에 포함된 서비스별 권장 사항을 따르는 것이 좋습니다. 자세한 내용은 AWS 보안 설명서를 참조하세요.
구현 및 구성 세부 정보는 조직의 특정 요구 사항 및 프로세스에 따라 크게 달라지기 때문에 ADDF에서는 이러한 주제를 다루지 않습니다. 대신 이러한 주제를 다루는 것이 조직의 핵심적인 책임입니다. 일반적으로 AWS 랜딩 존을 관리하는 팀은 ADDF 환경을 계획하고 구현하는 데 도움을 줍니다.
초기 설정
ADDF Deployment Guide/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에서 사용자 지정 모듈 작성
새로운 ADDF 모듈을 생성하거나 기존 모듈을 확장하는 것이 ADDF의 핵심 개념입니다. 모듈을 생성하거나 사용자 지정할 때 일반적인 AWS 보안 모범 사례와 안전한 코딩을 위한 조직의 모범 사례를 따르는 것이 좋습니다. 또한 조직의 보안 요구 사항에 따라 초기 및 주기적인 내부 또는 외부 기술 보안 검토를 수행하여 보안 문제의 위험을 더욱 줄이는 것이 좋습니다.
반복되는 ADDF 배포
ADDF Deployment Guide
이 접근 방식은 소스 리포지토리(SeedFarmer를 운영하는 로컬 코드 베이스)가 신뢰할 수 있는 소스이고 여기에 명시적으로 선언된 인프라가 배포에서 원하는 결과인 GitOps 패러다임을 따릅니다. GitOps에 대한 자세한 내용은 What is GitOps
반복되는 보안 감사
조직의 다른 소프트웨어와 마찬가지로 ADDF와 사용자 지정 ADDF 모듈 코드를 보안 위험 관리, 보안 검토 및 보안 감사 주기에 통합합니다.
ADDF 업데이트
ADDF는 지속적인 개발 노력의 일환으로 정기적인 업데이트를 받습니다. 여기에는 기능 업데이트, 보안 관련 개선 및 수정이 포함됩니다. 정기적으로 새 프레임워크 릴리스를 확인하고 적시에 업데이트를 적용하는 것이 좋습니다. 자세한 내용은 Steps to update ADDF
서비스 해제
더 이상 필요 없는 경우 AWS 계정에서 ADDF와 모든 관련 리소스를 삭제합니다. 사용되지 않는 무인 인프라는 불필요한 비용과 잠재적인 보안 위험을 초래합니다. 자세한 내용은 Steps to destroy ADDF
