ブログ

IaC(Infrastructure as Code)セキュリティとは?

Google Cloudとコンテナの継続的なセキュリティ

本文の内容は、2022年2月21日現在における、Sysdig Cloud Native Learning Hub上のWhat Is Infrastructure as Code (IaC) Security?(https://sysdig.com/learn-cloud-native/cloud-security/what-is-infrastructure-as-code-iac-security/) を元に日本語に翻訳・再構成した内容となっております。

Infrastructure-as-Code(IaC)は、あらゆる種類の環境において、ITのプロビジョニングと管理戦略の中核を成すコンポーネントとなっています。クラウド、オンプレミス、またはそれらの組み合わせでアプリケーションを実行している場合でも、IaCはインフラストラクチャーのセットアップとアプリケーションの大規模展開を自動化するために不可欠です。

しかし、IaCにはさまざまなメリットがありますが、IaCに伴うセキュリティリスクに対処しなければ、自らの首を絞めることになります。実際、IaCは大規模な環境に最小限の人手で構成を展開するため、IaCのセキュリティ問題が環境全体のセキュリティ問題に発展する可能性があります。

この記事では、IaCのセキュリティについて知っておくべきことをすべて説明します。IaCセキュリティ・リスクがどのように発生するのか、IaCテンプレートが環境のプロビジョニングに使用された場合、どのように本番システムに広がるのか、そしてIaCセキュリティの脅威を軽減するためにチームが使用できるツールとプラクティスについて説明します。

IaCとは?

IaCセキュリティを理解するためには、まずIaCの仕組みを理解する必要があります。

簡単に言えば、IaCとは、IT環境を構築するためのアプローチであり、エンジニアは、リソースを手動で設定するのではなく、リソースがどのように設定されるべきかを定義する機械可読のポリシーファイルを記述します。これらのリソースは、ベアメタルサーバ、仮想マシン、ローカルファイルシステム、クラウド上のオブジェクトストレージバケット、ローカルまたはクラウドベースのアプリケーションなど、事実上あらゆるタイプのIT資産です。

IaCは、1つの設定を何百、何千ものリソースに完全に自動化された方法で適用することができるため、IT環境を大規模に設定する際に中心的な役割を果たします。また、IaCは、同じポリシーファイルに基づいている限り、各リソースに適用される設定は同一であるため、リソースの一貫した設定を保証します。

このような利点もあり、過去10年間でIaCが広く採用されてきました。特に、複数のクラウドにまたがる複雑な環境や、何百、何千もの個別リソースを含む環境では、それぞれのリソースを手動で設定することは不可能です。つまり、現代の多くの環境では、IaCは単なる必要な手法ではなく、ITのプロビジョニングと管理に絶対不可欠な要素となっているのです。

IaCのフレームワークには様々なものがあります。あるものは、特定のパブリック・クラウドなど、特定のタイプの環境でのみ機能します。また、環境に依存せず、ほとんどの場所で使用できるものもあります。しかし、IaCセキュリティの観点からは、どのIaCフレームワークも大きな違いはありません。

IaCのセキュリティリスク

セキュリティの観点から見ると、IaCは諸刃の剣のようなものです。

一方で、IaCには、人為的なミスによってIT環境にセキュリティの誤設定をもたらすリスクを軽減するという、本来のセキュリティ上のメリットがあります。言い換えれば、リソースを手動で設定するエンジニアが、重要なセキュリティ設定を適用し忘れたり、誤ったユーザーにアクセス権を与えたりすることを心配する必要がなくなります。

一方で、IaCには、IaCポリシーファイルのセキュリティ問題が、そのファイルを使って設定されたすべてのリソースに影響を与えるという、大きなセキュリティリスクがあります。つまり、たった1つのファイルのセキュリティ問題が、一挙に何百、何千ものリソースに広がるリスクとなるのです。

IaCのセキュリティリスクの例として、以下のIaCテンプレートを考えてみましょう。このテンプレートは、CloudFormation(AmazonクラウドのネイティブIaCフレームワーク)を使って、AWS S3オブジェクトストレージのバケットを設定することができます。

{
"Type" : "AWS::S3::Bucket",
"Properties" : {
"AccelerateConfiguration" : AccelerateConfiguration,
"AccessControl" : String,
"AnalyticsConfigurations" : [ AnalyticsConfiguration, ... ],
"BucketEncryption" : BucketEcryption,
"BucketName" : String,
"CorsConfiguration" : CorsConfiguration,
"IntelligentTieringConfigurations" : [ IntelligentTieringConfiguration, ... ],
"InventoryConfigurations" : [ InventoryConfiguration, ... ],
"LifecycleConfiguration" : LifecycleConfiguration,
"LoggingConfiguration" : LoggingConfiguration,
"MetricsConfigurations" : [ MetricsConfiguration, ... ],
"NotificationConfiguration" : NotificationConfiguration,
"ObjectLockConfiguration" : ObjectLockConfiguration,
"ObjectLockEnabled" : Boolean,
"OwnershipControls" : OwnershipControls,
"PublicAccessBlockConfiguration" : PublicAccessBlockConfiguration,
"ReplicationConfiguration" : ReplicationConfiguration,
"Tags" : [ Tag, ... ],
"VersioningConfiguration" : VersioningConfiguration,
"WebsiteConfiguration" : WebsiteConfiguration
}
}



ほとんどの点で、これは安全なテンプレートです。しかし、小さな、しかし潜在的に重要なミスが1つ含まれています。以下のパラメータにタイプミスがあります。

"BucketEcryption" : BucketEcryption,


Encryption "という単語に "n "が抜けていることに注目してください。その結果、テンプレートの適用時にCloudFormationがこの設定を正しく認識できません。

このパラメータは、このテンプレートが設定するS3バケットに保存されているデータに対して、デフォルトで構成を強制するために使用されるため、この小さなエラーは、S3データが暗号化されないことを意味します。このテンプレートを使用してAWS上のクラウドストレージを設定するエンジニアは、データが暗号化されていないにもかかわらず、デフォルトで暗号化されていると思い込んでしまうかもしれません。このテンプレートを使って何十、何百ものストレージバケットを設定すると、それぞれのバケットにセキュリティリスクが存在することになります。

また、IaCのセキュリティリスクにつながるのは、タイプミスだけではありません。例えば、上記のIaCテンプレートでは、S3バケットへのパブリックアクセスをブロックするパラメータが含まれていません。これは必ずしも安全ではありませんが、S3バケットに保存されているデータが一般に表示されるべきではない場合、セキュリティ上の問題となる可能性があります。

IaCセキュリティとは?

このようなリスクを改善するためのソリューションがIaCセキュリティです。IaCセキュリティとは、エンジニアがIaCテンプレート内のセキュリティ問題を発見し、修正するためのツールとプラクティスのことです。

ここでは、IaCセキュリティを、ツールとプラクティスという2つの重要な要素に分けて説明します。

IaCセキュリティ・ツール

IaCセキュリティツールは、IaCテンプレートをスキャンし、テンプレートがリソースのプロビジョニングに使用される前に、上述のタイプミスや、セキュリティの観点から重要な設定がないなどのセキュリティリスクを特定することができる設定監査員で構成されています。

これらのツールは、IaC ファイル内のすべてのタイプのセキュリティ・リスクを検出できるという保証はありませんが、IaC を使用する本番環境にセキュリティ問題を持ち込む可能性を大幅に低減することができます。

IaCのセキュリティ・プラクティス

IaCセキュリティ・プラクティスは、IaCテンプレートを作成または適用する際に、セキュリティ問題を引き起こすリスクを最小限に抑えるためにエンジニアが使用すべきプロセスを定義しています。したがって、IaCセキュリティプラクティスは、IaCに関連するセキュリティリスクを軽減するためのITガバナンスの一形態と考えることができます。

IaCセキュリティのベスト・プラクティス

どのIaCフレームワークを使用するか、あるいはどのようなタイプのリソースを設定するかにかかわらず、IaCに関連するセキュリティ・リスクを軽減するために、いくつかのステップがあります。

テンプレートのスキャン

IaCのセキュリティリスクに対処するための最も重要なステップは、IaCテンプレートを適用する前にスキャンすることです。前述のように、IaCのスキャンは、セキュリティ侵害につながる可能性のある見落としやミスを検出することができます。

プロダクションシステムのスキャン

IaCスキャンの限界は、IaCテンプレートの設定に基づいて、セキュリティ設定を一般的に評価することです。そのため、IaCスキャンでは、IaCを使って設定された後に特定の個別リソースに適用される設定に存在するセキュリティリスクを検出することができません。

例えば、あるストレージバケットのセキュリティ要件が他のバケットと異なる場合があります。両方のバケットが同じ IaC テンプレートを使用して作成されている場合、テンプレートをスキャンしても、各バケットがセキュリティの観点から適切に設定されていることを確認する効果は限定的です。

このような理由から、本番環境内の実際の設定を、設定・導入後にもスキャンする必要があります。高度な構成監査ツールは、各リソースの構成を詳細に評価し、潜在的なリスクを警告することができます。

安全なテンプレートの使用

セキュリティに配慮したテンプレートのコアセットを作成し、それをベースにして新しいテンプレートを作成することで、セキュリティ問題のリスクを軽減することができます。この方法は、新しいテンプレートをゼロから作成する(またはインターネット上で見つけたテンプレートをベースにする)よりも安全性が高く、セキュリティ問題の原因となる見落としのリスクを高めることができます。

IaCセキュリティ設定のデフォルト値の設定

IaCテンプレートにデフォルトで含まれる必要のある主要なセキュリティ・パラメータに関するルールを設定することを検討してください。例えば、データ・ストレージ・リソースの設定に使用されるIaCファイルでは、デフォルトでデータを暗号化する必要があるというルールを遵守することが求められます。

テンプレートの作成と適用ができる人を定義する

IaCは比較的簡単に使用することができ、基本的なスクリプトの知識があれば誰でもIaCテンプレートを作成し適用することができます。しかし、だからといって、チーム内の誰もが同じようにIaCを使用する際にセキュリティのベスト・プラクティスに従うことができるとは限りません。そのため、誰がIaCテンプレートの作成を許可し、誰がそれを適用できるかを定義するルールを設定することを検討してください。

まとめ

Infrastructure-as-Codeは、セキュリティ・リスクを軽減する面もありますが、1つのポリシー・ファイル内の小さな設定ミスが、数百または数千のリソースに影響を与える重大なリスクとなる可能性を大幅に高めます。

この事実に加え、IaC への依存度が高いことから、IaC のセキュリティ確保は、最新のセキュリティ戦略の重要な要素となっています。IaCのセキュリティは、IaCテンプレートをスキャンすることで実現できますが、本番環境を評価し、IaCのセキュリティ問題のリスクを軽減するためのベストプラクティスを確立することも必要となります。

Sysdigに関するお問い合わせはこちらから

最近の投稿

カテゴリー

アーカイブ

ご質問・お問い合わせはこちら

top