この記事はFinatextグループ Advent Calendar 2024 7日目の記事です。
はじめに
こんにちは。インフラエンジニアのぐらにゅです。
突然ですが、みなさんはTerraformを使っている中で、設定ミスをコード側で検知したいと思ったことはないでしょうか？
クラウドインフラを利用するケースが多いと思いますが、設定ミスがあると脆弱性を生んだりガバナンス違反をしていたなど、何らかのセキュリティ上のリスクが発生する可能性があります。
手動での変更も含めて網羅的にケアしたい場合にはクラウドインフラ側でガードレールを設けた方が良いですが、コード側でも検知できると嬉しいなあと思ったので、設定ミスを検知できるツールをいくつか調査してみました。
この記事で書くこと/書かないこと
書くこと
- 設定ミスを検知するツールとしてどういうものがあるか
- ツール選定する際に考えたいこと
書かないこと
- Terraformに関する話全般
- 設定ミスを検知する各ツールの具体的な使い方
この記事の結論
4つのツールを調べた結果、それぞれのツールに特性があるので、技術選定の際にはどういう機能を持ったツールを使いたいかをちゃんと考えたほうが良さそうだなと感じました。
以下は技術選定する際に考えたり確認した方がいいなと感じた点です。
- 検知したい設定ミスが一般的なものなのか、それとも組織や業界のガバナンスに関わることなのかをあらかじめ整理する
- マネージドポリシーを利用する場合には、対象となるクラウドリソースやそのルールの中身が自分たちの検知したい設定ミスとどのくらいマッチしているのか確認する
- ツールによってCI/CDパイプラインとの相性があるので、組み込みやすさなど使い勝手を考慮する
ツールを比較する
今回は以下の4つのツールについて概要レベルで調べました。
- Trivy（旧tfsec）
- Checkov
- Sentinel
- Conftest
またツールの比較に関して、以下の観点から情報を整理しました。
- 一般的な設定ミスについてはマネージドポリシーで管理できると嬉しいので、ツールからポリシーが提供されているかどうか
- 組織のガバナンスに関する設定ミスを検知を行いたい場合には自分たちでルールを作成する必要があるので、カスタムルールが作成可能かどうか
また使用例として「SecurityGroupのIngressでSSHをフルオープンで開けている」ケースがどのように検知できるのかについても記載します。
Trivy（旧tfsec）
TrivyはAqua Security社が開発しているOSSで、コンテナイメージやインフラリソースなどの脆弱性やシークレット情報をスキャンできるツールです。
tfsecがTrivyに吸収されたので、Terraformの設定ミスも検知できるようになっているようです。
Trivyでは以下のマネージドポリシーが提供されています。
またカスタムポリシーをRegoで書くことができます。
使用例
マネージドポリシーにS3 Bucket Public Access Blockが提供されているので、マネージドポリシーを使って検知することができそうです。
trivyをinstallした上で、以下のコマンドで実行すると実際にACL/Policiesどちらもpublic access blockの設定がされていないことが検知できました。
> trivy config .
HIGH: No public access block so not blocking public acls
═════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════
S3 buckets should block public ACLs on buckets and any objects they contain. By blocking, PUTs with fail if the object has any public ACL a.
See https://avd.aquasec.com/misconfig/avd-aws-0086
HIGH: No public access block so not blocking public policies
═════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════
S3 bucket policy should have block public policy to prevent users from putting a policy that enable public access.
See https://avd.aquasec.com/misconfig/avd-aws-0087
CIとして組み込みたい場合、例えばGithubだと公式Actionの提供もあるので、比較的簡単に組み込むことができそうです。
利用方法などの詳細は以下のページを参照してください。
Checkov
CheckovはPalo Alto Networks社が開発しているOSSで、IaCテンプレートやコンテナイメージ、Gitリポジトリ内の脆弱性の検知や、misconfigurationの検知、ポリシーによるガバナンス違反の検知ができるツールです。
Checkovでは以下のマネージドポリシーが提供されています。
カスタムポリシーはPythonとyamlで書くことができます。
使用例
マネージドポリシーとしてS3 Bucket Public Access Blockが提供されているので、マネージドポリシーを使って検知することができそうです。
trivyをinstallした上で、以下のコマンドで実行すると実際にACL/Policiesどちらもpublic access blockの設定がされていないことが検知できました。
> checkov --file s3.tf
Check: CKV_AWS_53: "Ensure S3 bucket has block public ACLS enabled"
FAILED for resource: aws_s3_bucket_public_access_block.example
File: /s3.tf:5-12
Guide: https://docs.prismacloud.io/en/enterprise-edition/policy-reference/aws-policies/s3-policies/bc-aws-s3-19
Check: CKV_AWS_54: "Ensure S3 bucket has block public policy enabled"
FAILED for resource: aws_s3_bucket_public_access_block.example
File: /s3.tf:5-12
Guide: https://docs.prismacloud.io/en/enterprise-edition/policy-reference/aws-policies/s3-policies/bc-aws-s3-20
CIとして組み込みたい場合、例えばGithubだと公式Actionの提供もあるので、比較的簡単に組み込むことができそうです。
利用方法などの詳細は以下のページを参照してください。
Sentinel
Hashicorp社が提供しているPolicy as Codeを実現するフレームワークです。
Sentinelでは以下のマネージドポリシーが提供されています。
カスタムポリシーはSentinelの独自言語を利用して記述します。
使用例
マネージドポリシーだと(Beta) Pre-written Sentinel Policies for Center for Internet Security(CIS) AWS S3 Foundations Benchmarkの1ルールとして提供されています。
利用される場合には2024/12/02にAWSとHashicorpが共同開発したポリシーを提供し始めたの機能であるためまだまだ数は少ないこと、オープンベータ版であることに留意する必要がありそうです。
マネージドポリシー/カスタムポリシー問わず、Sentinelを利用する場合にはHCP Terraform/Terraform EnterpriseにログインするとGUI上で簡単に設定することができそうです。
Conftest
ConfitestはOPAコミュニティ傘下のOSSです。yamlやjson、DockerfileやHCLなどなど様々なファイル形式に対してテストができるツールです。
マネージドポリシーは提供されておらず、ポリシーはRegoで記述します。
使用例
Conftestではマネージドポリシーが提供されていないため、自分でRegoを利用してポリシーを記述することになります。
今回のケースの場合は、例えば以下のリポジトリのコードのように書くことで検知ができそうです（自分でサンプルを書きたかったのですが、パッと書くには難易度が高かったのでいつかチャレンジしたいです）
まとめ
一言に「設定ミス」と言っても、クラウドを利用する上で一般的に発生するものなのか、それとも組織や業界のガバナンスに関するものなのかによってアプローチ方法が異なってきます。
ツールを選定する際には、以下の点を考慮に入れた上で検討することが大切になってくるのではないかなと感じました。
自分たちが検知したい「設定ミス」の特性を考える
検知したいと考えている「設定ミス」が、一般的な設定ミス・組織や業界のガバナンスに関わる設定ミスのどちらの比重が高いのかを考えた上で、ツール選定をした方がいいなと感じました。
一般的な設定ミスの場合、マネージドポリシーを利用して検知する方が、安全性やポリシーの維持管理がしやすいなどの利点があるので、マネージドポリシーを提供しているツールを選定した方が良さそうです。
一方でガバナンスに関わる設定ミスを検知したいという比重が高く、一般的な設定ミスの検知に重きを置いていない場合には、ConftestなどのPolicy as Codeを実現できるツールをいれるというアプローチもありそうです。
マネージドポリシーと検知したいクラウドリソースとのマッチ度
それぞれのツールによって検知する設定ミスが少しずつ異なっています。
自分たちが使っているクラウドリソースが検知されるのか、検知されるとしてどの範囲なのかなどはあらかじめ把握した上で選定すると良さそうです。
利用しているCI/CDパイプラインツールとの親和性
各ツールの情報を調べていて、普段TerraformをどのCI/CDパイプラインツールと組み合わせて使っているかによっても選ぶツールが変わってきそうだなと感じました。
たとえば以下に例としてツールとCI/CDパイプラインツールの組み合わせに関して記載します。
- TrivyとCheckovはGithub Actionsが提供されているため、Githubを利用している場合には簡単にworkflowに組み込める
- ConftestについてはCIツールであるAtlantisでサポートされている[1]ので、もしAtlantisを利用している場合には組み合わせて使うことができる
- SentinelはHCP Terraformに機能の一部として組み込まれており、GUI上で簡単に設定することができる
おわりに
調べる中で「設定ミス」と言っても、そのミスがどういう性質のものかによってアプローチ方法が変わるなあと感じました。
設定ミスをなくすことはなかなか難しいので、こういうツールを利活用することによって、安心安全にTerraformでクラウドインフラを管理できるとよさそうです。
Discussion