ポリシーをコードとして捉える：なぜ今必要？どのように役立つのか？

人為的なエラーや外部からの悪用によるデータ漏洩やシステム障害に関するニュースをどれほど頻繁に目にしますか？影響を受けた企業で IT に従事している場合、その直接的および間接的な影響は重大であり、このレベルの影響は IT 業界全体に及びます。いくつかのデータポイントを考えてみましょう。Splunk の 2023 年のセキュリティの状態に関する報告書によると、攻撃の高度化が調査対象者の38%にとって最大の課題であり、28%は高い作業負荷のために反応的な対応モードに陥っています。IBM の 2023 年のセキュリティ侵害のコストに関する報告書では、データ漏洩の平均コストは 445 万米ドルであり、過去 3 年間で 15% の増加を示しています。このような統計は、攻撃や報告される脆弱性の高度化と量の増大が継続して見られることを示しています。これに伴い、漏洩のリスクや財務的な影響も増大しています。そのため、スピードを落とすことではなく、よりスマートな対応が必要になっています。

ほとんどの企業は、過去10年間、ビジネスアプリケーションやサービスをモダナイズし、ハイブリッドクラウドに移行して、現在の需要のかつてないほどの高まりに対して、より迅速かつ俊敏に対応できるようにしてきました。これに加えて、私が関わる顧客のほとんどは、エッジや AI などのテクノロジーが追加されるにつれ、環境の複雑さに取り組んでおり、その取り組みの終点が見えない状況です。

これは、企業全体の AI ワークロードについては何を意味するのでしょうか。皆さんは、さらに多くのハイブリッド・インフラストラクチャ上で膨大なデータを処理しており、テクノロジー・インフラストラクチャへの負荷の高い AI ベースのアプリケーションを実行している、または実行することを検討しておられることでしょう。ソリューションの管理を自動化していない場合、これは非常に難しいシナリオとなり、手作業によるプロセスは、AI ソリューションやイノベーションの進展を遅らせる可能性があります。

コンプライアンスのニーズに対応し、ミッションクリティカルなワークロードの運用面での一貫性を促進する

AI が組み込まれるようになった複雑な環境において、俊敏性を維持するには、コストをコントロールし、リスクを軽減し、一貫性を維持するために内部および外部のポリシーと連携して機能させる必要があります。内部および外部のガバナンス、リスク、およびコンプライアンス (GRC) 管理が必要ですが、これを自動化するなら、よりスマートに俊敏性を維持することができます。

多くの場合、お使いのミッションクリティカルなシステムは、組織の収益を生み出したり、生産性を向上させたり、内外のコンプライアンス遵守事項の影響を最も受けるプロセスを制御するのに役立ちます。これらのシステムには安全性と高い性能があり、監査可能である必要があり、違反が少なく、適切な修復プロセスが備わっている必要があります。これらすべてには追加の時間と作業サイクルが必要となり、すべての必要な義務に対応する必要があります。監査人や評価担当者も情報を必要とするため、これらの対応によって重要なアプリケーションの構築と運用のプロセスに投入されるはずの時間が奪われてしまいます。その結果、チームのそれぞれのメンバーにフラストレーションが生じ、開発からテスト、本稼働までの流れにおける速度と効率が失われます。

内部および外部の GRC プロセスに関して、次のことが可能な場合を想像してください。

• 面倒で時間のかかる手動の検証プロセスを、アクションを起こす前に実行される自動化されたシームレスなチェックに置き換える。
• 迅速で効率的な自動プロセスを通じてコンプライアンスをスケールアップする。
• チーム全体に最適化された体験を提供し、チームが主要な責任分野に集中できるようにし、プロセスに対する全体的な満足度を向上させる。

Policy as Code による自動化は、複雑性を管理し、リスクを軽減し、ビジネス上のステークホルダーが皆さんのチームに期待する速度と俊敏性を維持した上で要求の厳しい AI やその他のアプリケーションを立ち上げるのに役立つベストプラクティスです。自動化された Policy as Code により、ハイブリッドクラウド・コンピューティングでの進歩を維持しながら、全体的な GRC 体制を改善することができます。

ポリシーを適用するための予測可能でシームレスな機能があると、一貫性のある運用が可能になるため、テクノロジースタックに対する信頼性が高まります。スキルのギャップの運用に対する影響度は低くなり、違反と問題の原因となりがちな人為エラーを減らすことができます。Policy as Code の自動化は、チームが直面する生産性の低下に対処するのに役立ちます。

ライフサイクル全体での Policy as Code の自動化

Policy as Code の自動化は、検証とコンプライアンスポリシー・チェックをシームレスに行うことを可能にするより良い方法です。Red Hat Ansible Automation Platform は、お客様が IT プロセス内および IT プロセス全体で自動化を行い、スピードや効率、俊敏性、また当然のことながら ROI を実現するために使用されるよく知られた自動化プラットフォームです。 これは、ほぼすべての IT プロセスを自動化できる非常に柔軟なソリューションであり、Policy as Code の自動化も自動化されるプロセスに含まれます。チームは、以下を実行するために自動化された Policy as Code を使用できます。

• 作成：開発サイクルの段階でポリシーの施行を自動的にチェックし、開発者がシームレスにコンプライアンスに準拠した開発およびテストプラットフォームを構築し、コンプライアンスをプロダクション環境やコードに最初から組み込むことを可能にします。チームが時間のかかる会議や手動による再確認なしに、適用可能なポリシーをすべて適用できます。
   
• 管理：必要に応じてポリシー適用を統合できます。たとえば、これには、自動化ジョブが実行される前後の裁量に任されて行うポリシーチェックや必須のポリシーチェックが含まれます。スタック内にコンプライアンスを逸脱したテクノロジーある場合にアラートを受け取り、必要に応じて自動的に応答します。クラウドやその他のテクノロジーインスタンスが構成仕様を満たしていることを確認し、コストを制御でき、一貫性と信頼性のある運用環境を確保できるようにします。ポリシー変更の影響を受ける可能性のあるインベントリーを容易に特定でき、変更を自動的に適用できます。
   
• スケール：監査関連のシステムへの報告および出力を自動化し、報告に関連するチームへの全体的な負担を軽減します。

Ansible Playbook にポリシーを含めることで、Policy as Code を今すぐ自動化できます。これらは手動または自動化コントローラーによって実行できます。Event-Driven Ansible (Ansible Automation Platformの一部) を追加すると、ポリシーの逸脱が生じ、可観測性または監視ツールがこの逸脱にフラグを付けたり、必要に応じてこれを修正する際に、エンドツーエンドの応答を自動化できます。

完全自動化された Policy as Code の準備

これは実現できれば素晴らしいことですが、大規模に、かつ組織全体で実現するにはどうしたらよいでしょうか。ここに準備できるいくつかの方法を紹介します。

• 自動化の利用を拡大する。チーム (ネットワーク、クラウド、インフラストラクチャ、セキュリティ、アプリケーション開発、SRE など) は、単一の一貫性のある自動化プラットフォームを使用していますか？企業全体で自動化の利用を拡大していく場合、ドメイン内および複数のドメイン間で自動化を実行して、テクノロジースタック全体でポリシーの整合性を保つことができます。自動化を拡大することにより、ミッションクリティカルなワークロードやアプリケーションに自動化された Policy as Code を実装できるようになります。
• 自動化を「as Code」モデルでモジュール化し、一元化する。ポリシーをベンダーに依存せずに作成し、ポリシーを一元化し、特定のベンダーソリューションに適用したり、Ansible Playbook や Ansible Rulebook に含めたりすることはできるでしょうか。そのためには、標準の構成ファイル、Playbook、および一貫性のある方法で使用することを希望しているその他の自動化資産を保存するための中央リポジトリを特定できます。これは Infrastructure as Code および/または Configuration as Code モデルの分野であり、これにより体系化が可能となり、Policy as Code の自動化を追加することができます。
• 自動化されたコンプライアンスニーズを評価し、チームを効果的に編成する。遵守する必要のある重要なコンプライアンスおよびセキュリティ要件を特定し、主要なマイルストーンと目標を含むロードマップを設定します。チームを召集し、目標、利点、役割、責任について共通の理解を確認します。すべてのポリシーがデプロイメント・ワークフローで使用される前に実装され、テスト済みであることを確認するなど、運用に向けた準備を行います。
• 監視と適用のあり方を見据える。重要なアプリケーションやワークロードが稼働すると、ポリシー違反を監視し、これに対応する方法を決定します。1 つのオプションとして、イベント駆動型の自動化を使用して、セキュリティリスクやリスクを伴う構成変更に対して即座に、また手動介入なしで対応することができます。
• 自動化コミュニティ・オブ・プラクティスのリーダーを任命する。Red Hat は、自動化の使用を拡大するためにこのアプローチを何年も推奨してきました。このリーダーは、自動化全般に対応し、Policy as Code の自動化を実現するための自動化を立ち上げる手助けをします。The Automation Architect’s Handbook は、社内コミュニティを組織化するためのいくつかのアイデアを提供しています。

Policy as Code を使い始める：「小さく始めて、大きく考える」アプローチ

取り組みのどの段階にあっても、自動化された Policy as Code は GRCに役立ちます。コンプライアンスについては、アプリケーションをサポートするテクノロジースタック全体に対応する必要があるため、自動化を拡大し、単一の一元化されたソースから自動化を行うことを視野に入れてください。この段階に至っていない場合でも、ポリシーを自動化することは可能ですが、その場合、ポリシーはおそらくより内部向けのものになるでしょう (たとえば、特定のバージョンの　Linux では、環境で実行するために特定のセキュリティポリシーを適用する必要があります)。

Red Hat の全体的アプローチは、単純なユースケースから始め、そこからスコープと線練度を拡大していくというものです。Policy as Code は次のように実装できます。たとえば、考えられるユースケースには次のようなものがあります。

• 特定のポリシーに準拠していないシステムについてのインベントリーレポートを収集する。

• 「ファイアウォールは特定のポートでのみ開くことができる」といったランタイムポリシーを適用する。

• クラウド関連のコストを制御するために、特定のサイズを超えないクラウドインスタンスを作成する。

• 特定のサーバーで変更を自動化するには、そのサーバーがメンテナンス期間内にある場合のみとする。

Policy as Code に関するシンプルなユースケースを実装できるようになったら、数を増やしたり、より高度なものを展開したりできます。

自動化された Policy as Code に関する Red Hat の見解を理解していただいた後、皆さんにはこの分野および時間のかかるプロセスを軽減するためにこれを活用する方法について検討していただくことを希望しています。最後に、Ansible Automation Platform は非常に柔軟であること留意していただきたいと思います。実装する対象が定まれば、このプラットフォームは、Policy as Code に関して必要なアクションを実行する場合でも優れた機能を発揮します。Policy as Code をライフサイクル全体でより簡単かつスマートに機能させるためにできることはまだまだ数多くあります。