cfn_nag
v0.8.10
CFN-NAG 도구는 불안한 인프라를 나타낼 수있는 CloudFormation 템플릿의 패턴을 찾습니다. 대략적으로 말하면 다음을 찾을 것입니다.
이 도구에 대한 자세한 내용은 Stelligent의 블로그 에서이 게시물을 참조하십시오.
"CFN-NAG"를 사용하여 CloudFormation 템플릿의 개발 프로세스 초기에 보안 문제 찾기
Ruby> = 2.5.x가 설치되었다고 가정하면 설치는 다음과 같습니다.
gem install cfn-nagMacOS 또는 Linux에서는 Brew로 설치할 수 있습니다.
brew install ruby brew-gem
brew gem install cfn-nag CodePipeline에서 cfn_nag 작업으로 실행하려면 AWS Serverless Application Repository를 통해 배포 할 수 있습니다.
실행하려면 :
cfn_nag_scan --input-path < path to cloudformation json > 경로는 디렉토리 또는 특정 템플릿 일 수 있습니다. 디렉토리 인 경우 모든 .json, .template , .yml 및 .yaml 파일은 하위 디렉터로의 재귀를 포함하여 처리됩니다.
기본 출력 형식은 자유 형식 텍스트이지만 --output-format json 플래그로 JSON 출력을 선택할 수 있습니다.
선택적으로 --debug 플래그는 규칙 로딩 내부에 대한 정보를 덤프합니다.
지원되는 스위치의 전체 목록을 위해 --help 로 실행하십시오.
CFN-NAG의 모든 규칙 목록을 보려면 현재 지원하는 명령 줄 유틸리티가 있습니다.
cfn_nag_rules 편의를 위해 dockerfile이 제공됩니다. DockerHub에 stelligent/cfn_nag 로 게시됩니다.
https://hub.docker.com/r/stelligent/cfn_nag
로컬로 만들 수도 있습니다.
docker build -t stelligent/cfn_nag .템플릿이 포함 된 로컬 디렉토리를 Docker 컨테이너에 장착 한 다음 컨테이너에서 CFN_NAG를 호출 할 수 있습니다. 이 예제는 단위 테스트 CFN_NAG에 사용되는 테스트 템플릿을 사용합니다.
$ docker run -v ` pwd ` /spec/test_templates:/templates -t stelligent/cfn_nag /templates/json/efs/filesystem_with_encryption.json
{
" failure_count " : 0,
" violations " : [
]
}
$ docker run -v ` pwd ` /spec/test_templates:/templates -t stelligent/cfn_nag /templates/json/efs/filesystem_with_no_encryption.json
{
" failure_count " : 1,
" violations " : [
{
" id " : " F27 " ,
" type " : " FAIL " ,
" message " : " EFS FileSystem should have encryption enabled " ,
" logical_resource_ids " : [
" filesystem "
]
}
]
} cfn_nag_scan 지속적인 통합 파이프 라인 동안 코드를 평가하기 위해 GitHub 워크 플로의 일부로 실행할 수 있습니다.
GitHub 워크 플로우 파일에서 CFN_NAG 작업을 사용하는 단계를 만듭니다.
- name : Simple test
uses : stelligent/cfn_nag@master
with :
input_path : testsGitHub 동작에 대한 자세한 내용은 여기를 참조하십시오.
CFN-NAG는 "프로파일"의 개념을 지원하며, 이는 효과적으로 적용 할 규칙 목록입니다. 프로필은 한 줄에 규칙 식별자를 포함 해야하는 텍스트 파일입니다. --profile-path 명령 줄 인수를 통해 지정되면 CFN-NAG는 해당 특정 규칙의 위반 만 반환합니다.
"프로필"을 만드는 동기는 다른 개발자가 다른 규칙에 관심을 가질 수 있다는 것입니다. 예를 들어, "infrastructure_developer"는 IAM 규칙에 관심을 가질 수 있지만 "APP_Developer"는 IAM 리소스를 만들지 못하므로 해당 규칙에 신경 쓰지 않을 수도 있습니다.
다음은 예제 프로필입니다.
F1
F2
F27
W3
W5
거부 목록은 기본적으로 프로필의 반대입니다. 적용 할 수있는 규칙 목록입니다. --deny-list-path 명령 줄 인수를 통해 지정된 경우 CFN-NAG는 파일에 지정된 특정 규칙에서 위반을 반환하지 않습니다.
규칙이 둘 다에 지정된 경우, 거부 목록은 프로파일보다 우선 순위가 있으며 규칙은 적용되지 않습니다.
형식은 다음과 같습니다. 유일한 두 가지 중요한 필드는 RulesToSuppress 와 항목 당 id 입니다. 그 reason CFN-NAG에 의해 해석되지 않지만 규칙을 적용해서는 안되는 이유를 정당화하고 문서화하는 것이 좋습니다.
RulesToSuppress :
- id : W3
reason : W3 is something we never care about at enterprise X 억제하려는 규칙이있는 경우 cfn_nag Metadata 키를 영향을받는 리소스에 추가하여 CFN_NAG에게 해당 규칙에 대한 실패 또는 경고를 제기하지 않도록 지시 할 수 있습니다.
예를 들어, 다음과 같은 리소스를 사용하여 인터넷에서 인바운드 연결에 공개되는 공개 ELB를 설정하는 경우 다음과 같은 리소스가 있습니다.
public_alb.yaml
# Partial template
PublicAlbSecurityGroup :
Properties :
GroupDescription : ' Security group for a public Application Load Balancer '
VpcId :
Ref : vpc
Type : AWS::EC2::SecurityGroup
PublicAlbSecurityGroupHttpIngress :
Properties :
CidrIp : 0.0.0.0/0
FromPort : 80
GroupId :
Ref : PublicAlbSecurityGroup
IpProtocol : tcp
ToPort : 80
Type : AWS::EC2::SecurityGroupIngressCFN_NAG는 다음과 같은 경고를 제기합니다.
$ cfn_nag_scan -i public_alb.yaml
------------------------------------------------------------
public_alb.yaml
------------------------------------------------------------------------------------------------------------------------
| WARN W9
|
| Resources: [ " PublicAlbSecurityGroup " ]
|
| Security Groups found with ingress cidr that is not /32
------------------------------------------------------------
| WARN W2
|
| Resources: [ " PublicAlbSecurityGroup " ]
|
| Security Groups found with cidr open to world on ingress. This should never be true on instance. Permissible on ELB
Failures count: 0
Warnings count: 2메타 데이터를 추가하면 이러한 경고를 억제 할 수 있습니다.
public_alb_with_suppression.yaml
# Partial template
PublicAlbSecurityGroup :
Properties :
GroupDescription : ' Security group for a public Application Load Balancer '
VpcId :
Ref : vpc
Type : AWS::EC2::SecurityGroup
Metadata :
cfn_nag :
rules_to_suppress :
- id : W9
reason : " This is a public facing ELB and ingress from the internet should be permitted. "
- id : W2
reason : " This is a public facing ELB and ingress from the internet should be permitted. "
PublicAlbSecurityGroupHttpIngress :
Properties :
CidrIp : 0.0.0.0/0
FromPort : 80
GroupId :
Ref : PublicAlbSecurityGroup
IpProtocol : tcp
ToPort : 80
Type : AWS::EC2::SecurityGroupIngress $ cfn_nag_scan -i public_alb_with_suppression.yaml
------------------------------------------------------------
public_alb_with_supression.yaml
------------------------------------------------------------
Failures count: 0
Warnings count: 0CloudFormation 템플릿 매개 변수는 배포 지점에 값이 지정되므로 정적 분석에 문제를 제시 할 수 있습니다. 다시 말해, 정적 분석이 완료 될 때 값을 사용할 수 없습니다. 정적 분석은 그 앞에있는 "코드"만 볼 수 있습니다. 따라서 CIDR이 매개 변수화되고 배포 시간에 0.0.0.0/0이 전달되는 경우 0.0.0.0/0의 보안 그룹 인스 레스 규칙이 플래그가 지정되지 않습니다.
매개 변수 값을 확인할 수 있도록 사용자는 명령 줄에 전달 된 JSON 파일의 매개 변수 값을 cfn_nag 및 cfn_nag_scan --parameter-values-path=<filename/uri> flag로 지정할 수 있습니다.
JSON의 형식은 단일 키 "매개 변수"이며, 값은 매개 변수에 각 키/값 쌍 매핑이있는 사전입니다.
{
"Parameters" : {
"Cidr" : " 0.0.0.0/0 "
}
}이것은 다음 매개 변수에 "0.0.0.0/0"을 제공합니다.
Parameters :
Cidr :
Type : String JSON에 추가 매개 변수가있는 경우 조용히 무시 됩니다 ( cfn_nag_scan 모든 템플릿에 동일한 JSON을 적용 할 수 있도록).
JSON이 기형이 있거나 위 사양을 충족하지 않으면 치명적인 위반으로 구문 분석이 실패합니다.
0.5.55 이전에 FN :: FindInMap에 대한 호출은 효과적으로 무시되었습니다. 기본 모델은 그것들을 남겨두고 규칙에 대한 해시 값으로 나타납니다. 예를 들면 다음과 같습니다. { "Fn::FindInMap" => [map1, key1, key2]}
0.5.55에서 시작 하여이 모델은 FindInMap에 대한 호출 값을 계산하고 해당 값을 규칙에 제시하려고 시도합니다. 이 평가는 다음의 키를 지원합니다.
평가 로직이 키의 값을 파악할 수없는 경우 전체 표현식을 위해 해시를 반환하는 이전 동작으로 기본값이됩니다.
또한 0.5.55 이전에는 AWS 유사 결여에 대한 호출이 효과적으로 무시되었습니다. 기본 모델은 그것들을 남겨두고 규칙에 대한 해시 값으로 나타납니다. 예를 들면 다음과 같습니다. {"Ref"=>"AWS::Region"} . 일반적인 사용 사례는 영역별로 매핑을 구성하는 것이므로, 가전 기능 평가는지도 평가를 더 잘 지원하는 데 중요합니다.
0.5.55에서 시작 하여이 모델은 기본값이있는 규칙에 다음과 같은 AWS 유사 기능을 제공합니다.
'AWS::URLSuffix' => 'amazonaws.com',
'AWS::Partition' => 'aws',
'AWS::NotificationARNs' => '',
'AWS::AccountId' => '111111111111',
'AWS::Region' => 'us-east-1',
'AWS::StackId' => 'arn:aws:cloudformation:us-east-1:111111111111:stack/stackname/51af3dc0-da77-11e4-872e-1234567db123',
'AWS::StackName' => 'stackname'
또한 최종 사용자는 기존 매개 변수 대체 메커니즘을 통해 제공되는 값을 무시할 수 있습니다. 예를 들어:
{
"Parameters" : {
"AWS::Region" : " eu-west-1 "
}
}CFN_NAG의 버전 0.4.66까지, 기본 모델은 템플릿 내에서 fn ::의 처리를 수행하지 않았습니다. 이것은 속성에 조건부 값이있는 경우 fn :: if를 구문 분석하는 것이 규칙에 달려 있음을 의미했습니다. FN ::가 어디에서나 나타날 수 있다는 점을 감안할 때 규칙 개발자들에게 멍청한 상황을 만들었습니다. 기껏해야 규칙 논리는 값이 처음에 해시가 아니라고 가정 한 해시 값을 무시할 수 있습니다.
이 문제를 해결하기 위해 CFN_NAG의 기본 동작은 이제 실제 결과를 가진 경우 fn ::를 대체하는 것입니다. 이는 기본적으로 규칙이 보안 위반에 대한 잘못된 결과를 검사하지 않는다는 것을 의미합니다.
속성 값 수준에서 fn ::를 대체하는 것 외에도, 동일한 동작이 최상위 수준의 속성에있는 경우에 동일한 동작이 적용됩니다. 예를 들어:
Resource1 :
Type : Foo
Properties : !If
- IsNone
- Description : Up
- Description : DOwn다음과 동일하게 보입니다.
Resource1 :
Type : Foo
Properties :
Description : Up 이 동작에 대한 약간의 제어를 제공하기 위해, 사용자는 명령 줄에 전달 된 JSON 파일의 cfn_nag 및 cfn_nag_scan 모두에게 --condition-values-path=<filename/uri> 플래그를 모두 지정할 수 있습니다.
JSON의 형식은 조건에 대한 각 키/값 쌍 매핑과 함께 AA 사전입니다.
{
"Condition1" : true ,
"Condition2" : false
}SPCM의 기초는 블로그 게시물 사고 실험 제안 된 복잡성 메트릭에 설명되어 있습니다.
CFN_NAG의 버전 0.6.0에서 시작 :
spcm_scan CloudFormation Templates (예 : CFN_NAG_SCAN) 디렉토리를 스캔하고 JSON 또는 HTML 형식의 SPCM 메트릭으로 보고서를 생성 할 수 있습니다.cfn_nag_scan --rule-arguments spcm_threshold:100 통해 제어 할 수 있습니다.--rule-arguments 메커니즘을 통해 설정에 대한 최종 사용자 값을 받아들이는 규칙을 개발할 수 있습니다. 규칙 객체는 attr_accessor (예 : attr_accessor :spcm_threshold 및 cfn_nag) 만 선언하면됩니다 --rule-arguments 0.5.x의 릴리스에는 사용자 정의 규칙 (CAN)이 배포되고로드되는 방식에 대한 몇 가지 주요 변경 사항이 포함됩니다. 이 릴리스 이전에는 규칙이로드 된 두 곳이있었습니다 : Core CFN_NAG GEM 내의 lib/cfn-nag/custom_rules 디렉토리 및 명령 줄에 지정된 사용자 정의-룰 디렉토리.
사용자 정의 규칙이 어떻게/위치가로드되는지에 대한 재 설계를 강요 한 두 가지 사용 사례가 있습니다. 규칙 로딩 메커니즘은 규칙 규칙 저장소를 사용하여 규칙을 발견 할 수 있도록 일반화되었습니다.
파일 시스템에 앉아있는 "규칙 파일"은 전통적인 소프트웨어 개발 관점에서 크지 않습니다. 이 파일에는 버전이나 추적 성이 없으므로 0.5.x는 "CFN_NAG RULE GEM"이라는 개념을 소개합니다. 개발자는 별도의 보석의 일부로 맞춤 규칙을 개발하고 버전을 설치할 수 있습니다. 그리고 그 규칙은 보석 메타 데이터에 cfn_nag_rules => true 포함 된 한 cfn_nag에서 참조됩니다. "CFN-NAG-HIPAA-RULES"와 같은 보석의 경우 Lib/CFN-NAG-HIPAA-RULES 하의 *.rb가로드됩니다. CFN-NAG/BASE_RULE (CFN-NAG/CUSTOL-RULES/BASE 아님 )의 CFNNAG :: Baserule에서 사용자 정의 규칙이 파생되어야합니다. 규칙이 다른 것에서 파생되어야하는 경우 메소드 cfn_nag_rule? 이로 인해 True를 반환하면 규칙적으로로드됩니다.
CFN_NAG가 AWS Lambda에서 실행될 때 - 전통적인 의미에서는 파일 시스템 ( /TMP 외에)이 없습니다. 따라서 Lambda에서 핵심 규칙 만 사용할 수 있습니다. CFN_NAG는 사용자 정의 규칙을 지원하기 위해 파일 시스템 대신 S3 버킷에서 규칙을 찾는 것을 지원합니다.
루비에서 맞춤 규칙을 개발하는 방법에 대해 볼 수있는 모든 것은 여전히 사실입니다.
S3 버킷에서 규칙을 발견하려면이 내용으로 파일 s3.yml 을 만듭니다.
---
repo_class_name : S3BucketBasedRuleRepo
repo_arguments :
s3_bucket_name : cfn-nag-rules-my-enterprise
prefix : /rules접두사 /규칙 (예 : /rules/mynewrule.rb)이있는 버킷 CFN-NAG-RULES-MY-ENTERPRISE에 *rule.rb 파일을 적용하려면 다음과 같은 명령 줄 에이 파일을 지정하십시오.
cat my_cfn_template.yml | cfn_nag --rule-repository s3.yml 규칙이 둘 이상의 버킷에있는 경우 여러 S3*.IML 파일을 생성하고 --rule-repository 인수로 지정하십시오.
Ambient AWS 자격 증명에 버킷 cfn-nag-rules-enterprise 에 액세스 할 수있는 권한이 있다면 /rules/*Rule.rb 와 같은 모든 규칙을 찾을 수 있습니다. 특정 aws_profile을 사용해야하는 경우 repo_arguments (예 : aws_profile: my_aws_profile 에서 키로 추가하십시오.
파일 시스템 외에도 GEM 설치 및 S3- 새로운 아키텍처는 이론적으로 다른 "규칙 저장소"개발을 지원하여 DynamODB, 관계형 데이터베이스 또는 기타 웹 서비스의 규칙을로드합니다.
자신의 사용 및/또는 커뮤니티 기여에 대한 새로운 규칙을 작성하려면 자세한 내용은 사용자 정의 규칙 개발을 참조하십시오.
수프 투 넛 TDD 맞춤형 규칙 개발을 보여주는 스크린 캐스트는 다음과 같습니다.
https://www.youtube.com/watch?v=jrzct0nafd4&t=1601s
사양을 실행하려면 Docker를 설치하고 CFN_NAG 종속성을 통해 설치해야합니다.
gem install bundle
bundle install 그런 다음 모든 사양을 실행하려면 rake test:all 실행하십시오.
엔드 투 엔드 테스트를 실행하려면 rake test:e2e 실행하십시오. 스크립트는 Gemfile의 모든 보석을 묶고 CFN_NAG GEM을 로컬로 빌드 및 설치 한 다음 사양 종속성을 설치 한 다음 'END_TO_END'로 태그 된 테스트를 실행합니다. 또한 Amazon에서 제공하는 샘플 템플릿을 끌어 내고 CFN_NAG_SCAN을 실행하여 알려진 좋은 템플릿이 CFN-NAG 내에서 예외를 유발하는지 확인합니다.
현재 git 브랜치를 로컬로 설치하려면 :
bundle install
scripts/deploy_local.sh규칙 개발 및 생성에서 쉽게 구성되도록 사전 구성된 모든 도구 및 설정으로 완전한 원격 개발 환경이 생성되고 설정되어 있습니다. VS 코드 원격 개발 기능을 사용하여이를 활성화 할 수 있습니다.
Folder contains a dev container configuration file. Reopen folder to develop in a container Reopen in Container .[Dev Container] cfn_nag Development 옵션을 사용하십시오.VS Code 원격 개발 설정에 대한 자세한 내용은 Code 원격 개발을 참조하십시오.
버그를보고하거나 기능을 요청하려면 https://github.com/stelligent/cfn_nag/issues/new를 통해 Github 저장소를 통해 문제를 제출하십시오.
