コードとしてのインフラストラクチャ（Infrastructure as Code, IaC）は、事前構築されたテンプレートの形式でコードを活用し、クラウドベースのアプリケーションをサポートするために必要なインフラストラクチャリソースをプロビジョニングする手法を指します。再現性が高い手法で、開発者は、アプリケーションが実行されるインフラストラクチャを作成するコードの作成、テスト、リリースに使えます。このプロセス全体を、継続的インテグレーション・継続的デプロイメント（CI/CD）ソフトウェアパイプラインの一部として自動化できます。
IaCの導入で、新しいコードを本番環境にプッシュするたびに手動でリソースをプロビジョニングする必要がなくなるため、非常に有益な手法です。反復可能なタスクは自動化され、チームは製品をより速くデプロイできるようになります。
IaCを実装すると、開発者がより迅速かつ効率的に作業を進められるようになりますが、一般にこれにはデメリットを伴います。こうした速度の向上により、プラットフォームとDevOpsチームによる制御と監視が弱まることが多く、場合によってはリソースが不適切にプロビジョニングされたり、最悪の場合には安全でない方法で作成されたりするリスクが発生します。こうした事態に対抗するためか、Forresterの最近のレポートによれば、世界のセキュリティ部門の上級意思決定者の58%が2022年にアプリケーションセキュリティの予算を増やす計画を立てています。
ただ、開発サイクルにセキュリティを統合すると、SecOpsはDevOpsと歩調を合わせて可能な限り迅速にワークロードを適切に保護しようとするため、開発者とセキュリティ担当者の間に摩擦が生じる可能性があります。
それぞれの環境と目的は異なります。ツールにより向き不向きがあるため、特定のニーズに最適なツールを調査しておく必要があります。注目すべき点は、クラウドプロバイダの多くが自社のプラットフォームにネイティブなツールやサービスを提供していることです。特定のプラットフォーム採用時にすでに組み込まれている機能との重複を避けるため、調査の際にはこの点を考慮しましょう。
当社のアプローチの詳細を確認：クラウドセキュリティとDevOpsおよびCI/CDツールの統合
Terraformは、ユーザーが人間が判読できる形式の宣言型設定ファイルでリソースとインフラストラクチャを定義するのに役立ちます。複数のクラウドプラットフォーム上でインフラストラクチャのライフサイクルを管理できるだけでなく、デプロイメント全体でリソースの変更を追跡することもできます。
Chef Infraを使用すると、ユーザーは反復可能で一貫性があり、再利用可能なポリシーを定義して、設定管理を自動化できます。設定とポリシーをコードとして定義し、テストと強制が可能で、自動化されたパイプラインの一部として大規模に配信できます。必要に応じて設定からの逸脱を検知し、修正することもできます。
Puppetは、宣言型コードを使用してサーバー設定の管理と自動化を支援するツールで、組織のITニーズに合わせたインフラストラクチャの自動化を拡張できます。ユーザーは、目標に到達するために必要な手順ではなく、望ましいシステム状態を記述できます。
AWS CloudFormationは、ユーザーがDevOpsを使用してインフラストラクチャを管理するのに役立ちます。CI/CD自動化により、自動化、テスト、インフラストラクチャデプロイメントテンプレートの作成が可能になります。また、CloudFormationレジストリ、開発者コミュニティ、ユーザーライブラリで公開されているクラウドリソースを含めてインフラストラクチャを拡張・管理することもできます。
Ansibleは、オープンソースのコマンドラインIT自動化ソフトウェアアプリケーションで、システムの構成、ソフトウェアのデプロイ、高度なワークフローの調整を行い、アプリケーションのデプロイメントやシステムの更新などに対応できます。Ansibleはいわゆる「可動部分」を最小限に抑え、転送にOpenSSHを使用しており、人間が判読できる形式の言語を採用しているため、ユーザーはすぐに使い始めることができます。
SaltStackは、リモートタスクの実行と設定管理のためのPythonベースのオープンソースソフトウェアで、ユーザーが複雑なITシステムをデプロイして構成できるようにします。人間が判読できるYAMLとイベントドリブン型の自動化を組み合わせて、ITOps、DevOps、NetOps、SecOpsの各部門にメリットをもたらします。
クラウド環境におけるIaCの主なメリットは、前述のように速度ですが、もう少し深く掘り下げると、以下のように具体的なビジネス上のメリットが明らかになります。
現代の企業の大半が達成しようとしているマクロ的な利益としては、壮大な「シフトレフト」が挙げられます。これは、DevOpsとSecOpsを真のDevSecOps文化に統合し、セキュリティをCI/CDパイプラインへ移行し、セキュリティとコンプライアンスを事後対応的なスタンスから予防的なスタンスへと変えるものです。
ここまでの説明で明らかになった点は、IaCを定義する方法はたくさんあるということでしょう。もう少し掘り下げると、宣言型IaCと命令型IaCという2つの一般的な分類があります。簡単に言えば、これらは、開発者がIaC自動化プラットフォームに何をすべきかを指示する方法を指します。
この方法では、ユーザーは、望ましい結果を宣言し、システムに事前構築されたテンプレートとルールに依拠させることでシステムがその結果に到達するようにします。したがって、ユーザーに求められる設定プロセスに関する技術的知識は少なくなり、委任によって効率が向上します。ここでは、ユーザーは基本的に「プロセスが完了した後にこの結果が起こることを望んでいるが、それをどう行うかは気にしない」と言っているのです。また、ユーザーがアプリケーション全体の形成と展開についてより戦略的なアプローチを取れるというメリットもあります。
簡単に振り返ると、IaCとは、性質上、コードが実行されるクラウドインフラストラクチャを定義するステートメントを記述することです。宣言型IaCは、望む目的の結果に到達するためのより高速で簡単な方法であり、通常最も利用されている方法論です。
最終的な結果に至るまでの各ステップを定義する責任をユーザーが負うというと、大きな欠点のようにも聞こえ、場合によっては確かに難しい手法でしょう。この形式では、ユーザーにプログラミング言語についての深い知識が必要となり、運用全体を機能させるために各ステップを完璧に実行する必要もあります。メリットは、ユーザーが自動化プロセスとコードをより詳細に制御でき、状況に固有のニーズに合わせて設定プロセスをカスタマイズできることです。
これには、コントローラーに対して「このループを繰り返し、この境界条件をチェックし、条件が満たされている場合はこの操作を実行し、条件が満たされていない場合はこの別の操作を実行する」など、正確な指示をすることが含まれます。命令型プログラミングは本質的にマイクロマネジメントで、通常は人間主導で行われます。
IaCの導入で開発ライフサイクルの速度と効率が向上しても、セキュリティ上の懸念が生じないようにすることが重要です。そのために、プロセスのできるだけ早い時期にセキュリティ制御とチェック機能を実装することが不可欠です。そうすることで、問題が作り出される前にテンプレート内の問題を検出し、組織の標準に準拠していないリソースの作成を避けることができます。IaCの課題についてもいくつか見てみましょう（メリットの方が確実に大きいのでご心配なく）。