Infrastructure as Codeツールをどうすれば安全に利用できるか？

その名のとおり、Infrastructure as Code（IaC）とは、アプリケーションの実行基盤となるインフラをコードや設定ファイルで定義する手法です。これにより、リソースのプロビジョニングを自動化できるだけでなく、従来はアプリケーションのコードベースにのみ適用されていたライフサイクルプロセスを、インフラにも適用できます。IaCについて詳しく知りたい方は、IaCとは何か、そして実環境で利用する際のセキュリティ上の影響について解説したこちらの記事をご覧ください。

IaCを実装するためのインフラ自動化ツールは数多くあります。Amazon Web ServicesのCloudFormationやAzureのResource Manager（ARM）などのパブリッククラウドプロバイダーが提供するツールのほか、Hashicorp TerraformやPulumiのように複数のインフラプラットフォームに対応するプロジェクトもあります。

宣言型言語ベースのIaCツールは静的解析に適しており、定義したインフラがデプロイされる前にセキュリティ上の問題を検出・解決する能力を高めます。IaC分野におけるセキュリティのベストプラクティスは、今も継続的に見つかっています。Snyk IaC productの開発を進めるなかで、開発者が問題を把握するだけでなく、修正方法に関する背景情報やアドバイスも得られるようにすることで、組織がIaCをできるだけ簡単に導入できるよう取り組んでいます。

代表的なInfrastructure as Codeツールを取り上げ、アプリケーションやプラットフォームを保護するために、コードレベルで適用できるセキュリティ強化策をご紹介します。

Infrastructure as Codeツール

クラウドプロバイダーが提供するソリューション

AWS CloudFormation、Azure Resource Manager（ARM）、およびGoogle Deployment Manager（GDM）主要なクラウドプロバイダーはすべて、インフラのプロビジョニングを自動化する独自のIaCツールを提供しています。JSONやYAMLのテンプレートを使ってデプロイの望ましい状態を宣言的に定義でき、Google Deployment ManagerではJinjaやPythonも利用できます。

Amazon Cloud Development Kit（CDK）2019年にリリースされたAmazon Cloud Development Kit（CDK）では、JavaScript、Python、C#などの高水準プログラミング言語を使ってデプロイを定義できます（対応言語の一覧はこちら）。慣れ親しんだ構文を使えるだけでなく、IDEとの連携や、プロジェクト間でJSON/YAMLをコピー＆ペーストする代わりに、パターンを再利用可能なライブラリやテスト済みのコード構造としてパッケージ化することもできます。CDKの出力はCloudFormation JSONです。つまりAmazonは、実績あるCloudFormationのインフラオーケストレーションツールを活用しながら、開発者にとって使いやすい環境を提供しています。

マルチクラウド対応ソリューション

Hashicorp TerraformTerraformは、プロバイダープラグインを通じて、幅広いプラットフォームや製品のプロビジョニングと設定を自動化するツールです。

PulumiPulumiはオープンソースのIaCプロジェクトで、複数のプログラミング言語向けSDKを提供し、さまざまなプラットフォームでリソースをプロビジョニング、管理できます。

注意すべき問題とスキャンの例

利用するクラウドプロバイダーやIaCツールにかかわらず、セキュリティの観点から共通して注目すべき領域があります。TerraformとAWSの例を交えながら、いくつか見ていきましょう。これらの例はすべてこちらのGitHubリポジトリにあります。各例で見つかった潜在的な問題をSnyk IaCのスキャンツールがどのように表示するか、スクリーンショットもご紹介します。

認証情報

Gitリポジトリの最上位ディレクトリにあるmain.tfファイルには、よくある問題がいくつか見つかります。Snykのスキャンでは、以下のように重大度「高」が1件、「中」が5件報告されています。

まず、どのような認証情報であっても、ソース管理にチェックインしてはいけません。当たり前のことのように思えますが、インターネット上のフォーラムには、認証情報を含むコードリポジトリの例が数多くあり、その多くは誰でも閲覧できます。残念ながら、こうした例の多くは悪用されて初めて発見されました。多くの場合、不注意なユーザーが誤ってコミットしたことで起こります。特に厄介なのは、認証情報をコミットした後のコミットで削除するケースです。開発者が気づかなくても、その認証情報はリポジトリの履歴に残り続けます。.gitignoreファイルや、コミット前のフックスクリプトを使うなど、この問題を検出する方法はいくつかあります。たとえば、AWS Labsの「git-secrets」があります。

IAMアカウントのパスワードに関する問題もいくつか見つかります。AWSアカウントごとに設定できるポリシーは1つだけで、ポリシーを設定するとAmazonが提供するデフォルトポリシーが上書きされます。そのため、これらのオプションはすべて明示的に設定してください。

ストレージサービスの暗号化

EBSボリュームではデフォルトで暗号化が有効になっていますが、S3バケットでは有効になっていません。社内ポリシーや規制当局のガイドラインに準拠しているか、両方とも確認することが重要です。デモ用リポジトリでは、modules/storage/main.tfファイルにストレージリソースを2つ定義しています。以下のスキャン結果をご覧ください。

ここでは、両方の違反が検出されているほか、S3サーバーアクセスログが有効になっていないことを示す、優先度の低い警告も表示されています。いずれかの問題を詳しく見ると、その内容や影響に加え、解決方法の推奨事項を確認できます。

各ポリシーの重大度（高・中・低）は、組織のポリシーに合わせて変更することもできます。

セキュリティグループ／ファイアウォールのインバウンドおよびアウトバウンドの範囲

modules/vpc/main.tfファイルを見ると、インバウンドアクセスの範囲が想定以上に広く設定されているという、もう1つのよくある問題が見つかります。

ハードコードされた認証情報と同様に、これは開発やトラブルシューティング中に設定され、ほかの作業と一緒に誤ってソース管理にコミットされることがよくあります。この例では、ポート22をインターネット全体に公開したい人はまずいないでしょう。ここでは、実際にそうなっている可能性があります。ネットワークへのトラフィックとネットワークからのトラフィックを厳しく制限し、必要なIP範囲のみに許可することが重要です。

キーのローテーション

最後の例として、modules/pki/main.tfファイルを見てみましょう。ここでは、キーのローテーションを設定せずにキーを作成しています。

これも、セキュリティ強化の観点ではデフォルトの動作が最適とは限らないケースです。もちろん、この推奨事項は組織に別途キーをローテーションするプロセスがないことを前提としています。しかし、クラウドプロバイダーのキー管理サービスを利用している場合、こうした作業をサービスに任せるのが最善である可能性は高いでしょう。

IaCの取り組みはどれほど安全ですか？

IaCコードに簡単に入り込む問題の例をいくつかご覧いただきました。皆さんのコードは本当に安全だと言い切れるでしょうか？セキュリティを後回しにしてはいけません。今すぐリポジトリに対して、これらのチェックに加え、ほかのクラウドプロバイダーやKubernetesを対象としたチェックも無料で実行できます。問題がデプロイされたり悪用されたりする前に検出しましょう。

Snykの無料アカウントを作成し、リポジトリからプロジェクトを作成する手順に従ってください。数分で、検出された問題に対する実用的なアドバイスが得られます。