Infrastructure as Code (IaC)セキュリティとは？
SHARE:
Infrastructure-as-Code（IaC）は、あらゆるタイプの環境において、ITプロビジョニングや管理戦略の中核をなす要素となっています。クラウド、オンプレミス、またはそれらの組み合わせのいずれでアプリケーションを実行する場合でも、IaCはインフラストラクチャのセットアップとアプリケーションのデプロイメントを大規模に自動化するために不可欠です。
しかし、IaCが持つすべての利点も、IaCに伴うセキュリティ・リスクに対処しなければ、足元をすくわれることになります。実際、IaC は最小限の人的監視で大規模な環境全体に設定を展開するため、IaC のセキュリティ問題は、私たちの環境全体で広範なセキュリティ問題になりやすいのです。
この記事では、IaC セキュリティについて知っておくべきことをすべて説明します。IaC のセキュリティ・リスクがどのように発生するのか、IaC テンプレートが環境のプロビジョニングに使用された場合、そのリスクがどのように本番システムに広がる可能性があるのか、IaC のセキュリティ脅威を緩和するためにチームが使用できるツールやプラクティスについて説明します。
IaCとは？
IaCのセキュリティを理解するために、まずIaCの仕組みを理解しましょう。
簡単に言えば、IaC は IT 環境を設定するためのアプローチであり、エンジニアがリソースを手動で設定するのではなく、リソースの設定方法を定義する機械読み取り可能なポリシーファイルを記述します。これらのリソースは、ベアメタルサーバー、仮想マシン、ローカルファイルシステム、クラウド上のオブジェクトストレージバケット、ローカルまたはクラウドベースのアプリケーションなど、事実上あらゆるタイプのIT資産です。
IaCは、完全に自動化された方法で数百または数千のリソースに単一のコンフィグレーションを適用することを可能にするため、チームがIT環境を大規模にコンフィグレーションする際に中心的な役割を果たします。IaCはまた、各リソースに適用されるコンフィグレーションが同じポリシーファイルに基づいている限り同一であるため、リソースの一貫したコンフィグレーションを保証します。
このような利点から、過去10年間にIaCが広く採用されるようになりました。特に、複数のクラウドにまたがる複雑な環境や、数百、数千の個別リソースを含む環境では、各リソースを手動で設定することは現実的ではありません。つまり、多くの最新環境では、IaCは単なる便利な方法論ではなく、ITプロビジョニングと管理に必要不可欠なコンポーネントなのです。
様々なIaCフレームワークが存在しています。特定のパブリック・クラウドなど、特定のタイプの環境でのみ機能するものもあります。環境にとらわれず、ほとんどどこでも使えるものもあります。しかし、IaCセキュリティの観点からは、さまざまなIaCフレームワークの間に大きな違いはありません。
IaCセキュリティリスク
セキュリティの観点からは、IaC は諸刃の剣のようなものです。
一方では、IaC は、人為的なミスによって IT 環境にセキュリティの誤った設定が導入されるリスクを軽減するという意味で、本質的なセキュリティ上のメリットをもたらします。言い換えれば、リソースを手動で設定するエンジニアが、重要なセキュリティ設定を適用し忘れたり、誤ったユーザーにアクセス権を与えたりする心配がなくなります。
またもう一方では、IaC は、IaC ポリシー・ファイル内のセキュリティ問題が、そのファイルを使用して構成されるすべてのリソースに影響するという重大なセキュリティ・リスクをもたらします。つまり、たった1つのファイルのセキュリティ問題が、一挙に数百、数千のリソースに広がるリスクになる可能性があるのです。
aCセキュリティリスクの例として、CloudFormation（AmazonクラウドのネイティブIaCフレームワーク）でAWS S3オブジェクトストレージバケットをセットアップするために使用できる以下のIaCテンプレートを考えてみましょう：
{
"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
}
}Code language: JSON / JSON with Comments (json)ほとんどの点で、これは安全なテンプレートです。しかし、1つの小さく、潜在的に重大な間違いを含んでいます。以下のパラメータにタイプミスがあります：
"BucketEcryption" : BucketEcryption,Code language: JavaScript (javascript)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 を使用する際にセキュリティのベスト・プラクティスに従うことがチームの全員に等しく適しているとは限りません。このため、IaC テンプレートを作成することを許可される人と、テンプレートを適用できる人を定義するルールを設定することを検討してください。
結 論
Infrastructure-as-Code は、セキュリティリスクを低減する面もありますが、1 つのポリシーファイル 内の小さな構成ミスが、数百または数千のリソースに影響を及ぼす重大なリスクになる可能性も大幅に高まります。
この事実は、今日の IaC への広範な依存と相まって、IaC のセキュリティ確保がほとんどの最新のセキュリティ戦略にとって重要な要素であることを意味します。IaC のセキュリティは、IaC テンプレートをスキャンすることによって達成することもできますが、本番環境を評価し、IaC のセキュリティ問題のリスクを軽減するベストプラクティスを確立することも必要です。