クラウドリソースのカバレッジを高め、インフラストラクチャのドリフトを低減する
Stephane Jourdan
2022年3月23日
0 分で読めます廃止のお知らせ:管理対象リソースのドリフト検出
snyk iac describe --only-managed and snyk iac describe --driftを含む、管理対象リソースのドリフト検出は廃止されました。管理対象リソースのドリフト検出の提供終了日は2023年9月30日です。
開発者にとって、クラウド環境で実際に稼働しているものを最大限に可視化することは、安全性を保つうえで欠かせません。Infrastructure as Code(IaC)を使えば、クラウドインフラストラクチャを自動化し、クラウドへのデプロイを管理下に置いて、簡単に監査できます。しかし、インフラストラクチャのIaCカバレッジを100%にして維持するには、多くの課題があります。
クラウド環境で実際にデプロイされ稼働しているもののセキュリティが、私たちのセキュリティの上限です。多くの場合、私たちや他のチーム、認証済みサービスによる手作業が定期的に行われています。こうした変更はIaCや監査から見えず、設定ミスやセキュリティ上の懸念につながります。そこで重要になるのがドリフト管理です。まだIaCの管理下にないリソースや、何らかの理由で変更されたリソースをレポートで把握したいのです。
この記事では、Snyk IaCを活用して、IaC(Infrastructure as Code)の管理対象外のクラウドリソース(未管理リソース)や、想定された状態からドリフトしたリソース(管理対象リソース)を開発者が見つける方法をご紹介します。
環境をセットアップする
Snyk IaCでは、検出したリソースをTerraformリソースとして一覧表示できるため、検出対象となったクラウドサービスの部分を簡単に把握できます。たとえば、Amazon API Gateway v2のサービス1つは、少なくとも12個のTerraformリソースで構成されています。Snykが提供する検出情報をもとに、変更を元に戻すか、新しいリソースをインポートするか、あるいは新たな変更を削除するかをすばやく判断できます。
一緒に試すには、以下のTerraformファイルを使って、手順で使用する2つのAWSリソースを作成できます。ランダムなサフィックスが付いた「user1」という名前のIAMユーザー、アクセスキー、読み取り専用アクセス用のアタッチ済みポリシーが作成されます。
この記事の執筆時点では、Terraform v1.1.7とAWSプロバイダー v3.74.2を使用しました
以下のHCL設定を再利用します:
main.tf
このTerraform設定を適用します:
ディレクトリのルートにterraform.tfstateがあることを確認します:
また、IAMユーザーがAWS上に正常に作成されていることを確認します。
何もない状態から始める
まず、Terraformの管理下にないクラウドリソースをすべて一覧表示します:
Terraformの管理下にないリソースが大量に表示されるでしょう。これは有益な情報ですが、今回の目的にはあまり役立ちません。Snyk IaCには、検出されたリソースをすべて.snykポリシーファイルに追加して、一括で無視する機能が組み込まれています。
既存の未管理リソースをすべて無視して、先ほど作成した2つのリソースだけがある管理された環境で、より正確に作業できるようにしましょう:
もう一度スキャンし、検出されたドリフトが現在無視されていることを確認します(あとでインポートをスケジュールする時間は十分にあります)。
これで、クリーンな状態から始める準備ができました。
IAMでドリフトを起こしてみましょう!
実際の状況を再現するために、次の3種類のドリフトを作成します:
既存のIAMユーザーを変更する(元に戻す対象)
新しいIAMポリシーを手動でアタッチする(削除する対象)
新しいIAMユーザーを作成する(改善する対象)
そのために、AWS IAMコンソールに移動します。
タグを追加して既存のIAMユーザーを変更する
IAMユーザーのページで「user1」をクリックします
Tagsタブをクリックします
Edit Tagsボタンをクリックします
新しいキー(「environment」)と値(「production」)を追加します
Saveをクリックします
既存のIAMユーザーに強力なポリシーをアタッチする
IAMユーザーのページで「user1」をクリックします
Permissionsタブをクリックします
Add permissionsボタンをクリックします
Attach existing policies directlyをクリックします
Administrator Accessを選択します
Next: Reviewをクリックします
Add permissionsをクリックして確定します
別のIAMユーザーを手動で作成する
IAMユーザーのページでAdd Usersボタンをクリックします
User name:フィールドに「user2」と入力します
Access keyを選択します
Next: Permissionsボタンをクリックします
アクセス許可やタグは設定しません
Create userをクリックします(表示された認証情報は不要なので、破棄してかまいません)。
これで、Snyk IaCのドリフト検出を使って、こうした手動変更に対処する準備ができました。
管理対象・未管理のインフラストラクチャのドリフト
ここからは、Snyk IaCがこれらの変更をどのように検出するかを確認しましょう。まずはTerraformでまったく管理されていないリソースから始めます。
このスキャンでは、Terraformリソースの用語を使って次のように報告されました:
手動で作成したIAMユーザー「user2」と、そのIAMアクセスキー
Terraform管理下のIAMユーザー「user1」に手動でアタッチしたIAMポリシー。
次に、さまざまなTerraformステートで見つかった、Terraform管理下のリソースの変更だけを確認します:
このスキャンでは大きく異なる結果が報告され、所要時間も大幅に長くなりました(「未管理」スキャンモードの9秒に対して36秒)。
この出力から、HCL内で「user1」というリソース名で定義された「user1-84i30k」というIAMユーザーに、「environment」という名前のタグがあり、値が「production」に設定されていることがわかります。
対応計画
Snykのドリフト検出ツールにより、期待と実際の状態との予期しない差異が4つ見つかりました。この記事では、チームが次のように判断したとします:
IAMユーザー「user2」は本番環境で使用されているため、Terraformにインポートする。
セキュリティ上の理由から、IAMユーザー「user2」のアクセスキーをローテーションする。
「user1」がAdministratorであってはならない。
「user1」の新しいタグは要件上必要なので、Terraformにインポートする。
対象 | リソースタイプ | 名前 | ドリフトタイプ | アクション |
|---|---|---|---|---|
IAMユーザー |
|
| 未管理 | インポート |
IAMアクセスキー |
|
| 未管理 | ローテーション |
アタッチ済みIAMポリシー |
|
| 未管理 | 削除 |
IAMユーザーのタグ |
|
| 管理対象 | インポート |
デプロイパイプラインは修復手段ではない
Terraformのデプロイパイプラインはすでに整備されています。次にterraform applyが実行されたら、正常な状態に戻ると期待するかもしれません。
この場合、Terraformはどう動作するでしょうか?デプロイジョブは次のようになります:
Terraformは、手動で作成またはアタッチされたリソースを検出することを本来想定していません。変更されたリソースを単純に元の状態に戻します(この状況では望ましい動作ではありません)。
対象 | リソースタイプ | 名前 | ドリフトタイプ | アクション |
|---|---|---|---|---|
IAMユーザー |
|
| 未管理 | なし |
IAMアクセスキー |
|
| 未管理 | なし |
アタッチ済みIAMポリシー |
|
| 未管理 | なし |
IAMユーザーのタグ |
|
| 管理対象 | 元に戻す |
どの場合も、期待する情報は得られません:
手動で作成したIAMユーザーとアクセスキーは報告されない(役に立たない)
管理対象ユーザーに手動でアタッチしたAdministratorポリシーは報告されない(役に立たない)
管理対象ユーザーに手動で追加した重要なタグは元に戻される(有害)
この種の検出と作業には、別のタイプのツールが必要です。
カバレッジを改善する
未管理リソースのカバレッジは、現時点で50%です:
チームの計画に沿って改善していきましょう。
「user1」のIAMポリシーを削除する
まず、最も緊急で簡単な対応として、管理対象のIAMユーザー「user1」から「Administrator」ポリシーを削除します:
IAM > Users > 「user1」に移動します
Permissionsをクリックし、「AdministratorAccess」を削除します
これでAWSリソースのカバレッジは50%から60%に上がりました。
対象 | リソースタイプ | 名前 | ドリフトタイプ | アクション | ステータス |
|---|---|---|---|---|---|
IAMユーザー |
|
| 未管理 | インポート | |
IAMアクセスキー |
|
| 未管理 | ローテーション | |
アタッチ済みIAMポリシー |
|
| 未管理 | 削除 | * |
IAMユーザーのタグ |
|
| 管理対象 | 追加 |
続けましょう。
Terraformのデプロイパイプラインのブロックを解除する
現在、aws_iam_user.user1のタグに対する手動変更によってパイプラインがブロックされています。デプロイが行われると、タグはHCLの内容に戻されます。解決策は何でしょうか?Snyk IaCのドリフト出力を使ってTerraform設定を調整します。
次の情報が得られています:
この出力から、次のことがわかります:
名前が「user1」の
aws_iam_userリソースを探していますこのリソースはterraform.tfstate内にあります(数十、数百ものステートがある場合に非常に便利です)
新しいタグキー
environmentの値は「production」です。
IAMユーザーのリソースにenvironment = "production"を追加して更新すると、次のようになります:
これで、安全にTerraformのデプロイパイプラインのブロックを解除できます:
これで、現時点で「管理対象」のドリフトを修正できました:
対象 | リソースタイプ | 名前 | ドリフトタイプ | アクション | ステータス |
|---|---|---|---|---|---|
IAMユーザー |
|
| 未管理 | インポート | |
IAMアクセスキー |
|
| 未管理 | ローテーション | |
アタッチ済みIAMポリシー |
|
| 未管理 | 削除 | * |
IAMユーザーのタグ |
|
| 管理対象 | 追加 | * |
IAMユーザーuser2をインポートしてキーをローテーションする
次に「user2」に対処します。以下を行います:
Terraformにインポートする
キーをローテーションする
まずIAMユーザーをTerraformにインポートします。簡単な方法を1つご紹介します。
まず、Snyk IaCから情報を収集します:
リソースタイプ | 名前 |
|---|---|
|
|
aws_iam_user resourceはどのようにインポートするのでしょうか?Terraform公式ドキュメントによると、IAMユーザーは名前を使ってインポートできます。例: $ terraform import aws_iam_user.lb loadbalancer。
必須の引数はnameだけです。そこで、この基本構造をHCLファイルに追加しましょう:
次に、このユーザーをTerraformにインポートします:
カバレッジはどのように変化したでしょうか?確認してみましょう:
カバレッジは60%から80%に上がり、残るリソースは1つだけです。
対象 | リソースタイプ | 名前 | ドリフトタイプ | アクション | ステータス |
|---|---|---|---|---|---|
IAMユーザー |
|
| 未管理 | インポート | * |
IAMアクセスキー |
|
| 未管理 | ローテーション | |
アタッチ済みIAMポリシー |
|
| 未管理 | 削除 | * |
IAMユーザーのタグ |
|
| 管理対象 | 追加 | * |
キーをローテーションする
次にこの作業に取りかかりましょう。キーをローテーションし、Terraformに追加します。新しいキーを作成するために、まずHCLに追加します(たとえば、関係するチームに渡せます)。最後にAWSから古いキーを削除します。
aws_iam_access_keyのTerraformドキュメントはとてもわかりやすいので、user2の名前を引数に取るリソースを1つ作成するだけです:
先ほどデプロイパイプラインのブロックを解除したので、Terraformを使って安全に適用し、新しいキーを作成できます:
削除する古いキーがまだ残っています。Snyk IaCの出力から、キー名がAKIASBXWQ3AYQETE6OFRであることがわかっています。
このキーを削除する最も簡単な方法は次のとおりです:
IAM > Users > user2 > Security Credentialsに移動します
Snyk IaCが報告した
AKIASBXWQ3AYQETE6OFRという名前のキーを、無効化してから削除します。
現在のカバレッジを確認しましょう。
おめでとうございます!Snyk IaCのドリフト検出のおかげで、すべてが管理下に戻りました。
対象 | リソースタイプ | 名前 | ドリフトタイプ | アクション | ステータス |
|---|---|---|---|---|---|
IAMユーザー |
|
| 未管理 | インポート | * |
IAMアクセスキー |
|
| 未管理 | ローテーション | * |
アタッチ済みIAMポリシー |
|
| 未管理 | 削除 | * |
IAMユーザーのタグ |
|
| 管理対象 | 追加 | * |
まとめ
この記事では、Snyk IaCのドリフト検出によって手動で作成されたAWSリソースを見つけ、Terraformの用語と適切な情報を使ってレポートすることで、開発者がTerraformのHCLコードにリソースをインポートできることを紹介しました。また、変更を自動的に元に戻すことが必ずしも望ましいとは限らず、デプロイパイプラインとあわせて軽量なドリフト検出・アラートシステムが必要であることも確認しました。
すべてのインフラストラクチャはコードで管理されるべきだと、私たちは確信しています。そうすることで、エンジニアは問題に対するセキュリティのフィードバックと可視性を、できるだけ早く得られます。
そのためSnyk IaCは、AWSアカウントで実際に稼働しているすべてのリソースをTerraformコードにすばやく再統合し、IaCのカバレッジを全体的に高め、セキュリティ上の問題を減らすのに役立ちます。Snyk IaCは、クラウドセキュリティチームとエンジニアリングチームの間のフィードバックループを閉じ、エンジニアが理解しやすい言葉で実行可能な修正方法をエンジニアに直接伝えることで、より迅速な修正を実現します。
ソースコードの段階からインフラを保護
Snykはワークフロー内のIaCセキュリティとコンプライアンスを自動化し、構成ドリフトや不足しているリソースを検出します。



