cfn_nag
v0.8.10
Инструмент CFN-NAG ищет шаблоны в шаблонах облачной информации, которые могут указывать на небезопасную инфраструктуру. Грубо говоря, это будет искать:
Для получения дополнительной информации о инструменте, пожалуйста, посмотрите этот пост в блоге Stelligent's:
Поиск проблем безопасности в начале процесса разработки шаблона облачной информации с «CFN-NAG»
Предполагается, что Ruby> = 2.5.x установлен, установка - это всего лишь вопрос:
gem install cfn-nagНа MacOS или Linux вы можете альтернативно установить с помощью Brew:
brew install ruby brew-gem
brew gem install cfn-nag Чтобы запустить cfn_nag как действие в CodePipeline, вы можете развернуть через репозиторий приложения без сервера AWS.
Выполнить:
cfn_nag_scan --input-path < path to cloudformation json > Путь может быть каталогом или определенным шаблоном. .yml это каталог, .json, .yaml .template
Формат вывода по умолчанию является текстом свободной формы, но вывод JSON можно выбрать с помощью флага --output-format json .
Необязательно, флаг --debug будет выбросить информацию о внутренних органах загрузки правил.
Запустите с --help для полного списка поддерживаемых коммутаторов.
Чтобы увидеть список всех правил, которые в настоящее время поддерживает CFN-NAG, существует утилита командной строки, которая выбросит их в Stdout:
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 : testsБолее подробную информацию о действии GitHub можно найти здесь.
CFN-NAG поддерживает понятие «профиля», которое фактически является списком применения правил. Профиль представляет собой текстовый файл, который должен содержать идентификатор правил на строку. При указании аргумента командной строки --profile-path CFN-NAG вернет нарушения только из этих конкретных правил.
Мотивация создания «профиля» заключается в том, что разные разработчики могут заботиться о разных правилах. Например, «Infrastructure_developer» может заботиться о правилах IAM, в то время как «app_developer» может даже не иметь возможности создавать ресурсы IAM и, следовательно, не заботиться об этих правилах.
Вот пример профиля:
F1
F2
F27
W3
W5
Список отказа в основном противоположна профилю: это список правил, которые никогда не применяются. При указании аргумента командной строки --deny-list-path CFN-NAG никогда не вернет нарушения из тех конкретных правил, указанных в файле.
В случае, если правило указано в обоих, список DENY будет иметь приоритет над профилем, и правило не будет применено.
Формат выглядит следующим образом. Единственными двумя существенными полями являются RulesToSuppress и id на элемент. reason не будет интерпретирована CFN-NAG, но рекомендуется оправдать и документировать, почему правило никогда не должно применяться.
RulesToSuppress :
- id : W3
reason : W3 is something we never care about at enterprise X В случае, если есть правило, которое вы хотите подавить, в пострадавший ресурс может быть добавлен ключ Metadata cfn_nag , чтобы сообщить 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: 0Параметры шаблона облачной информации могут представлять проблему для статического анализа, поскольку значения указаны в точке развертывания. Другими словами, значения недоступны, когда статический анализ выполнен - статический анализ может смотреть только на «код», который находится перед ним. Поэтому правило проникновения группы безопасности 0,0.0.0/0 не будет помечено, если CIDR параметризован, а 0,0.0.0/0 передается во время развертывания.
Чтобы разрешить проверку значений параметров, пользователь может указать значения параметров в файле JSON, передаваемого в командной строке как для cfn_nag , так и cfn_nag_scan с флагом --parameter-values-path=<filename/uri> .
Формат 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, модель попытается вычислить значение для вызова для поиска и представить это значение правилам. Эта оценка поддерживает ключи:
Если логика оценки не может выяснить значение для ключа, она по умолчанию будет по умолчанию старого поведения возврата хэша для всего выражения.
Также до 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 "
}
}Вплоть до версии 0.4.66 CFN_NAG, базовая модель не выполняла никакой обработки fn :: Если в пределах шаблона. Это означало, что если собственность имела условное значение, это было правило, чтобы анализировать FN :: if. Учитывая, что Fn :: Если может появиться в любом месте, это создало ситуацию с моликой для разработчиков правил. В лучшем случае, логика правил может игнорировать значения, которые были хэш, предполагая, что значение не было хэшем в первую очередь.
Чтобы решить эту проблему, поведение по умолчанию для CFN_NAG теперь состоит в том, чтобы заменить FN :: Если с истинным результатом. По умолчанию это означает, что правила не будут проверять ложные результаты на предмет нарушений безопасности.
В дополнение к замене 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 описывается в блоге Perment Experiment, предложенную метрикой сложности для политических документов IAM.
Начиная с версии 0.6.0 CFN_NAG:
spcm_scan может сканировать каталог шаблонов облачной информации (например, CFN_NAG_SCAN) и генерировать отчет с метриками SPCM в формате JSON или HTMLcfn_nag_scan --rule-arguments spcm_threshold:100--rule-arguments . Объект правила должен только объявить attr_accessor , например, attr_accessor :spcm_threshold и cfn_nag позаботятся о деталях для ввода значений из --rule-arguments Выпуск 0.5.x включает в себя некоторые серьезные изменения в том, как пользовательские правила могут быть распределены и загружены. Перед этим выпуском было два места, в которых правила были загружены: каталог lib/cfn-nag/custom_rules в ядре CFN_NAG GEM, а также режиссера на пользовательском правиле, указанной в командной строке.
Существует два варианта использования, которые заставили перепроектирование того, как/где загружаются пользовательские правила. Механизм загрузки правил был обобщен таким образом, чтобы пользовательские репозитории правил могут использоваться для обнаружения правил.
Куча «файлов правил», сидящих в файловой системе, не очень хороша с традиционной точки зрения разработки программного обеспечения. В этих файлах нет версии или отслеживания, поэтому 0.5.x представляет понятие «драгоценного камня правила cfn_nag». Разработчик может разработать пользовательские правила как часть отдельного драгоценного камня, версию и установить его ... и эти правила ссылаются на CFN_NAG, пока метаданные GEM включают cfn_nag_rules => true . Для драгоценного камня, названного как «CFN-NAG-Hipaa-Rules», будет загружен любой *.RB в рамках Lib/Cfn-Nag-Hipaa-Rules. Любые пользовательские правила должны происходить из CFNNAG :: BASERULE в CFN-NAG/BASE_RULE ( не CFN-NAG/CUSTER-RULE/BASE). Если правило должно происходить из чего -то другого, определяя метод cfn_nag_rule? Это возвращает истину, также приведет к тому, что это будет загружено как правило.
Когда CFN_NAG работает в AWS Lambda - на самом деле нет файловой системы (кроме /TMP) в традиционном смысле. Следовательно, только основные правила используются из Lambda. Чтобы поддержать пользовательские правила, CFN_NAG поддерживает обнаружение правил из ведра S3 вместо файловой системы.
Все, что вы, вероятно, видели, как разработать пользовательские правила в Ruby, все еще верно.
Чтобы обнаружить правила из ведра S3, создайте файл s3.yml с этим контентом:
---
repo_class_name : S3BucketBasedRuleRepo
repo_arguments :
s3_bucket_name : cfn-nag-rules-my-enterprise
prefix : /rulesЧтобы применить *rule.rb файлы в ведре CFN-nag-rules-my-enterprise с префиксом /правилами (EG /Rules/mynewrule.rb), укажите этот файл в командной строке в CFN_NAG как таковой:
cat my_cfn_template.yml | cfn_nag --rule-repository s3.yml Если правила находятся в более чем одном ведре, то создайте несколько файлов S3*.yml и укажите их в аргументе --rule-repository .
Если у экологических учетных данных есть разрешение на доступ к ведру cfn-nag-rules-enterprise то он найдет все правила, такие как /rules/*Rule.rb . repo_arguments следует aws_profile: my_aws_profile конкретный AWS_PROFIL
Помимо файловой системы, GEM устанавливает и S3 - новая архитектура теоретически поддерживает разработку других «репозитории правил» для загрузки правил из DynamoDB, реляционных баз данных или других веб -служб.
Чтобы создать новые правила для вашего собственного использования и/или вклада сообщества, для получения подробной информации см. Пользовательское разработку правил.
Экранкаст, демонстрирующий суп-к орехам, здесь доступна разработка правил.
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 локально, установить специфические зависимости, а затем выполняет тесты, тегированные с помощью '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 -кода можно найти здесь, VS Code Remote Development.
Чтобы сообщить об ошибке или запросить функцию, отправьте проблему через репозиторий GitHub через: https://github.com/stelligent/cfn_nag/issues/new
