보안

보안 제어

Nx Plugin for AWS에서 스캐폴딩된 프로젝트에는 기본적으로 여러 보안 제어가 포함되어 있습니다. 이 페이지는 이러한 제어에 대한 개요와 자세한 내용을 위한 관련 가이드 링크를 제공합니다.

인프라 스캐닝

인프라 프로젝트는 build 타겟의 일부로 Checkov로 구성되어 있어, 안전하지 않은 인프라 구성은 빌드를 실패시킵니다:

CDK 프로젝트는 Checkov에서 스캔하는 CloudFormation 템플릿을 합성합니다. 자세한 내용은 보안 테스팅을 참조하세요.
Terraform 프로젝트는 Terraform 코드에 대해 직접 Checkov를 실행합니다. Terraform 프로젝트를 참조하세요.

제공된 인프라가 Checkov 규칙을 억제하는 경우, 억제는 특정 리소스로 범위가 지정되고 정당화 사유와 함께 주석이 달립니다. 공유 suppressRules 헬퍼는 모든 억제에 대한 이유를 요구하며, 자체 코드에서도 동일한 관행을 따르는 것을 권장합니다. Checkov 검사 억제를 참조하세요.

컨테이너 이미지 스캐닝

컨테이너 이미지를 빌드하는 프로젝트(예: 에이전트, MCP 서버 및 데이터베이스 마이그레이션 이미지)에는 HIGH 및 CRITICAL 취약점에 대해 이미지를 스캔하는 trivy 타겟이 포함되어 있으며, 발견 시 0이 아닌 값으로 종료됩니다. .trivyignore 파일로 발견 사항을 억제하는 방법을 포함한 자세한 내용은 Docker 번들링을 참조하세요.

자격 증명 스캐닝

워크스페이스에는 스테이징된 파일에서 AWS 자격 증명 패턴을 스캔하는 git-secrets 사전 커밋 훅이 포함되어 있어, 액세스 키 및 기타 민감한 값의 우발적인 커밋을 방지합니다. 워크스페이스 가이드의 Git Secrets 섹션을 참조하세요.

인증

API, 에이전트 및 MCP 서버는 기본적으로 AWS IAM(SigV4) 인증을 사용합니다:

tRPC, FastAPI 및 Smithy API는 기본적으로 IAM 인증을 사용하며, Cognito 및 사용자 지정 권한 부여자를 옵션으로 사용할 수 있습니다. 제공된 사용자 지정 권한 부여자 스텁은 기본적으로 요청을 거부합니다.
Amazon Bedrock AgentCore Runtime에 배포된 에이전트 및 MCP 서버는 기본적으로 IAM(SigV4) 인증을 사용하며, JWT 기반 Cognito 인증을 옵션으로 사용할 수 있습니다.
웹사이트 인증 생성기는 다단계 인증(MFA) 필수, 강력한 암호 정책 및 삭제 보호가 활성화된 Amazon Cognito 사용자 풀을 제공합니다.

암호화

제공된 인프라는 전송 중 및 저장 시 데이터를 암호화합니다:

웹사이트는 HTTP가 HTTPS로 리디렉션되는 CloudFront를 통해 제공되며, HTTP Strict Transport Security(HSTS), Content Security Policy 및 기타 보안 헤더를 포함하는 응답 헤더 정책이 적용됩니다. AWS 관리형 규칙이 있는 WAF가 배포와 연결됩니다.
S3 버킷은 모든 퍼블릭 액세스를 차단하고, 버킷 정책을 통해 SSL 전용 액세스를 강제하며, 암호화되고(웹사이트 콘텐츠의 경우 키 로테이션이 있는 KMS), 고객 관리형 KMS 키로 암호화된 CloudWatch 로그 그룹에 서버 액세스 로그를 전달하여 Logs Insights로 쿼리하고 알람을 설정할 수 있습니다.
API 액세스 로그는 로테이션이 활성화된 고객 관리형 KMS 키로 암호화된 CloudWatch 로그 그룹에 기록됩니다.
Aurora 데이터베이스는 고객 관리형 KMS 키로 스토리지 암호화를 활성화하고, AWS Secrets Manager에서 자격 증명을 생성하며(하드코딩되지 않음), 자동 자격 증명 로테이션을 지원합니다.

최소 권한

제공된 CDK 구성 요소 및 Terraform 모듈은 최소 권한을 따릅니다:

구성 요소는 grant* 메서드(예: API 및 에이전트의 grantInvokeAccess, 데이터베이스의 grantConnect)를 노출하여 소비자가 필요한 액세스만 부여할 수 있도록 합니다.
제공된 인프라의 IAM 정책은 특정 리소스 및 작업으로 범위가 지정됩니다. AWS 서비스에서 와일드카드 리소스가 필요한 경우(예: ecr:GetAuthorizationToken), 해당 작업으로 제한되고 지원되는 경우 조건으로 범위가 지정됩니다.

종속성 라이선싱

라이선스 생성기는 자동화된 라이선스 헤더 관리 및 승인된 라이선스 허용 목록에 대한 종속성 라이선스 검사를 구성하여, 문제가 있는 전이 종속성이 배포되기 전에 포착할 수 있도록 도와줍니다.

책임

보안 및 규정 준수는 공동 책임입니다. AWS는 이를 공동 책임 모델을 통해 설명하며, 이는 클라우드 자체의 보안(AWS의 책임)과 클라우드 내의 보안(고객으로서의 귀하의 책임)을 구분합니다.

Nx Plugin for AWS는 해당 모델의 귀하 측면의 일부를 해결하는 데 도움을 줍니다. 생성기는 안전한 기반을 제공하고 생성하는 코드의 범위 내에서 AWS 모범 사례를 인코딩합니다 — 위에서 설명한 제어입니다. 이는 안전하게 구축하는 데 필요한 노력을 줄이지만, 보안의 소유권을 플러그인으로 이전하지는 않습니다.

귀하는 워크스페이스에 생성된 코드를 소유하며 그 보안에 대한 책임이 있습니다. 일단 제공되면, 생성된 코드는 귀하가 수정, 확장 및 운영할 수 있으며, 귀하가 작성하는 다른 코드와 동일하게 취급되어야 합니다.

특히:

플러그인의 범위는 생성기로 제한됩니다. 플러그인은 애플리케이션의 비즈니스 로직, 데이터 분류, 위협 모델 또는 규제 의무에 대한 지식이 없으며, 이에 의존하는 결정을 내릴 수 없습니다.
인증은 구성되지만 권한 부여는 구성되지 않습니다. API는 기본적으로 인증(예: IAM/SigV4)으로 보호되지만, 플러그인은 어떤 인증된 주체가 어떤 리소스에 대해 어떤 작업을 수행할 수 있어야 하는지 결정할 수 없습니다. 세분화된 권한 부여는 비즈니스 로직에 따라 달라지며 귀하가 설계, 구현 및 테스트해야 합니다.
생성된 코드는 완제품이 아닌 시작점입니다. 기능을 추가하면 플러그인이 예상할 수 없는 보안 고려 사항이 도입됩니다 — 입력 유효성 검사, 데이터 처리, 비밀 관리, 종속성 선택 및 다른 시스템과의 통합.

따라서 생성된 코드와 그 위에 구축하는 애플리케이션을 자체 조직의 보안 정책, 표준 및 검토 프로세스에 따라 검토하고, 프로덕션 워크로드에 적용하는 것과 동일한 위협 모델링, 보안 테스팅 및 승인 게이트를 적용해야 합니다. 플러그인에서 제공하는 제어는 이러한 프로세스를 대체하는 것이 아니라 보완하기 위한 것입니다.