コードとしてのインフラストラクチャ(IaC)とは?

コードとしてのインフラストラクチャ(Infrastructure as Code, IaC)は、事前構築されたテンプレートの形式でコードを活用し、クラウドベースのアプリケーションをサポートするために必要なインフラストラクチャリソースをプロビジョニングする手法を指します。再現性が高い手法で、開発者は、アプリケーションが実行されるインフラストラクチャを作成するコードの作成、テスト、リリースに使えます。このプロセス全体を、継続的インテグレーション・継続的デプロイメント(CI/CD)ソフトウェアパイプラインの一部として自動化できます。

IaCの導入で、新しいコードを本番環境にプッシュするたびに手動でリソースをプロビジョニングする必要がなくなるため、非常に有益な手法です。反復可能なタスクは自動化され、チームは製品をより速くデプロイできるようになります。

IaCを実装すると、開発者がより迅速かつ効率的に作業を進められるようになりますが、一般にこれにはデメリットを伴います。こうした速度の向上により、プラットフォームとDevOpsチームによる制御と監視が弱まることが多く、場合によってはリソースが不適切にプロビジョニングされたり、最悪の場合には安全でない方法で作成されたりするリスクが発生します。こうした事態に対抗するためか、Forresterの最近のレポートによれば、世界のセキュリティ部門の上級意思決定者の58%が2022年にアプリケーションセキュリティの予算を増やす計画を立てています。

ただ、開発サイクルにセキュリティを統合すると、SecOpsはDevOpsと歩調を合わせて可能な限り迅速にワークロードを適切に保護しようとするため、開発者とセキュリティ担当者の間に摩擦が生じる可能性があります。

コードとしてのインフラストラクチャツール(IaC)

それぞれの環境と目的は異なります。ツールにより向き不向きがあるため、特定のニーズに最適なツールを調査しておく必要があります。注目すべき点は、クラウドプロバイダの多くが自社のプラットフォームにネイティブなツールやサービスを提供していることです。特定のプラットフォーム採用時にすでに組み込まれている機能との重複を避けるため、調査の際にはこの点を考慮しましょう。

当社のアプローチの詳細を確認:クラウドセキュリティとDevOpsおよびCI/CDツールの統合

Terraform

Terraformは、ユーザーが人間が判読できる形式の宣言型設定ファイルでリソースとインフラストラクチャを定義するのに役立ちます。複数のクラウドプラットフォーム上でインフラストラクチャのライフサイクルを管理できるだけでなく、デプロイメント全体でリソースの変更を追跡することもできます。

Chef Infra

Chef Infraを使用すると、ユーザーは反復可能で一貫性があり、再利用可能なポリシーを定義して、設定管理を自動化できます。設定とポリシーをコードとして定義し、テストと強制が可能で、自動化されたパイプラインの一部として大規模に配信できます。必要に応じて設定からの逸脱を検知し、修正することもできます。

Puppet

Puppetは、宣言型コードを使用してサーバー設定の管理と自動化を支援するツールで、組織のITニーズに合わせたインフラストラクチャの自動化を拡張できます。ユーザーは、目標に到達するために必要な手順ではなく、望ましいシステム状態を記述できます。

AWS CloudFormation

AWS CloudFormationは、ユーザーがDevOpsを使用してインフラストラクチャを管理するのに役立ちます。CI/CD自動化により、自動化、テスト、インフラストラクチャデプロイメントテンプレートの作成が可能になります。また、CloudFormationレジストリ、開発者コミュニティ、ユーザーライブラリで公開されているクラウドリソースを含めてインフラストラクチャを拡張・管理することもできます。

Ansible

Ansibleは、オープンソースのコマンドラインIT自動化ソフトウェアアプリケーションで、システムの構成、ソフトウェアのデプロイ、高度なワークフローの調整を行い、アプリケーションのデプロイメントやシステムの更新などに対応できます。Ansibleはいわゆる「可動部分」を最小限に抑え、転送にOpenSSHを使用しており、人間が判読できる形式の言語を採用しているため、ユーザーはすぐに使い始めることができます。

SaltStack

SaltStackは、リモートタスクの実行と設定管理のためのPythonベースのオープンソースソフトウェアで、ユーザーが複雑なITシステムをデプロイして構成できるようにします。人間が判読できるYAMLとイベントドリブン型の自動化を組み合わせて、ITOps、DevOps、NetOps、SecOpsの各部門にメリットをもたらします。

IaCのメリットは?

クラウド環境におけるIaCの主なメリットは、前述のように速度ですが、もう少し深く掘り下げると、以下のように具体的なビジネス上のメリットが明らかになります。

  • 手動設定のテンプレート化:従来、開発者はアプリケーションのデプロイメントの準備をするたびにインフラストラクチャを手動でプロビジョニングする必要がありました。IaCは、テンプレートを使用してこのプロセスを自動化します。SecOpsがセキュリティ制御を構築し、こうしたテンプレートを使用してガードレールを確立することで、反復可能なコードを迅速かつ効率的に活用できます。
  • リスクの軽減:リスクを完全に排除することは不可能ですが、組織のセキュリティ標準やベストプラクティスに合わせた反復可能なテンプレートを構築することで、人的ミスや脆弱性のリスクは軽減できます。
  • 無駄な支出の削減:人的ミスにより、誤構成されたリソースがプロビジョニングされたり、インフラストラクチャリソースが過剰にプロビジョニングされたりすることがよくあります。リソース量にガードレールを適用することで、過剰にプロビジョニングされたリソースに関連する無駄な支出を回避できます。
  • より強力なチームの構築:IaCにより、コスト削減だけでなく、技術的・運用面での効率向上も実現します。最大のメリットはおそらく、DevOpsとSecOpsとの間の摩擦が軽減されることでしょう。セキュリティがプロセスに自然に統合されていれば、セキュリティ組織がランタイム前に「開発者の作業をチェックしている」というような感覚はほぼなくなり、より前向きな作業環境とチームの仲間意識が生まれます。

現代の企業の大半が達成しようとしているマクロ的な利益としては、壮大な「シフトレフト」が挙げられます。これは、DevOpsとSecOpsを真のDevSecOps文化に統合し、セキュリティをCI/CDパイプラインへ移行し、セキュリティとコンプライアンスを事後対応的なスタンスから予防的なスタンスへと変えるものです。

宣言型 vs 命令型 IaC

ここまでの説明で明らかになった点は、IaCを定義する方法はたくさんあるということでしょう。もう少し掘り下げると、宣言型IaCと命令型IaCという2つの一般的な分類があります。簡単に言えば、これらは、開発者がIaC自動化プラットフォームに何をすべきかを指示する方法を指します。

宣言型 IaC

この方法では、ユーザーは、望ましい結果を宣言し、システムに事前構築されたテンプレートとルールに依拠させることでシステムがその結果に到達するようにします。したがって、ユーザーに求められる設定プロセスに関する技術的知識は少なくなり、委任によって効率が向上します。ここでは、ユーザーは基本的に「プロセスが完了した後にこの結果が起こることを望んでいるが、それをどう行うかは気にしない」と言っているのです。また、ユーザーがアプリケーション全体の形成と展開についてより戦略的なアプローチを取れるというメリットもあります。

簡単に振り返ると、IaCとは、性質上、コードが実行されるクラウドインフラストラクチャを定義するステートメントを記述することです。宣言型IaCは、望む目的の結果に到達するためのより高速で簡単な方法であり、通常最も利用されている方法論です。

命令型 IaC

最終的な結果に至るまでの各ステップを定義する責任をユーザーが負うというと、大きな欠点のようにも聞こえ、場合によっては確かに難しい手法でしょう。この形式では、ユーザーにプログラミング言語についての深い知識が必要となり、運用全体を機能させるために各ステップを完璧に実行する必要もあります。メリットは、ユーザーが自動化プロセスとコードをより詳細に制御でき、状況に固有のニーズに合わせて設定プロセスをカスタマイズできることです。

これには、コントローラーに対して「このループを繰り返し、この境界条件をチェックし、条件が満たされている場合はこの操作を実行し、条件が満たされていない場合はこの別の操作を実行する」など、正確な指示をすることが含まれます。命令型プログラミングは本質的にマイクロマネジメントで、通常は人間主導で行われます。

IaCの課題とは?

IaCの導入で開発ライフサイクルの速度と効率が向上しても、セキュリティ上の懸念が生じないようにすることが重要です。そのために、プロセスのできるだけ早い時期にセキュリティ制御とチェック機能を実装することが不可欠です。そうすることで、問題が作り出される前にテンプレート内の問題を検出し、組織の標準に準拠していないリソースの作成を避けることができます。IaCの課題についてもいくつか見てみましょう(メリットの方が確実に大きいのでご心配なく)。

  • テンプレートに含まれるセキュリティリスク:構築されたテンプレートにエラーがないとは限りません。危険なリソースが作成されるのを事前に避ける意味でも、使用前にテンプレートを確認することをお勧めします。
  • 分析の組み込み:IaCの導入後は、前述のように、脆弱性が体現する前にエラーを検出できるよう、スキャンツールも統合する必要があります。幸い、静的IaC分析と動的IaC分析のどちらも、コードの分析、誤設定の特定、IaCテンプレートが実行されるクラウド環境の評価に活用できます。
  • IaCの強化:IaCの実装と使用に際しては、習得までにある程度の時間がかかり、開発者のリソースが浪費され、チームが慣れ親しんでいるワークフローとは根本的に異なるワークフローが作成される可能性があります。さらに、IaCテンプレートリポジトリが開発チーム全体のニーズに確実に適合できる包括性を備えたものとなるよう、テンプレートを常に最新の状態に保つため、ステークホルダーチーム全体が計画に沿って対応することが重要です。
  • 人的な摩擦:IaCを実装する場合は、インフラストラクチャを誤設定や脆弱性から確実に保護するためにセキュリティツールを継続使用する必要があるため、開発者が混乱や速度低下に対処するのが難しくなる可能性があります。開発者がIaCテンプレートをいかにすばやく確認してシームレスに対応できるかは、セキュリティが左右します。

IaCセキュリティについてもっと読む

Rapid7のクラウドセキュリティプラットフォームがIaCセキュリティを提供する方法を確認

Rapid7ブログの最新のクラウドインフラストラクチャトピック

2022年クラウド誤設定レポート:最新のクラウドセキュリティ侵害と攻撃の傾向