インフラのコード化において必要なガードレールとドリフト検出

●
インフラのプロビジョニングは適切なプロセスや機能が伴わないと、果てしなく回り続ける車輪の中にいるような感覚に陥ります。この無限ループから脱する解決策は「インフラストラクチャのコード化（IaC：Infrastructure-as-Code）」を採用し、パブリッククラウドからプライベートデータセンターまで、複数の環境におけるプロビジョニングを自動化することです。

IaCはインフラを展開または変更する時の（人やワークフローなどの）ボトルネックをなくし、アプリケーションを提供するまでの時間を短くするというメリットをもたらします。しかしかつてのようなチケットベースのITプロセスではないため、注意が必要です。インフラの変更が、あらゆるセキュリティのベストプラクティスに従っていることを確認しないため、逸脱がないように“ガードレール”のようなものを設ける必要があります。

もし、IaCで標準化やガードレールがない場合どうなるでしょうか？多数の開発者と運用者が毎日動的にインフラをプロビジョニングしている環境では、次第にガバナンスが欠如し、コンプライアンスの維持が困難になります。結果として、セキュリティインシデントのリスクが高まることになります。

セキュリティは担保するだけではなく、ソリューションが効率的であることも確認していく必要があります。IaCはクラウド運用、IT、R&D、セキュリティ、エンジニアリング、コンプライアンス、財務など、複数のチーム間で部門横断的な目標を達成しながら、インフラをプロビジョニングする担当者らがコンポーネントを共同で再利用する上で役立ちます。さらに、セキュリティとデータガバナンスのコンプライアンスの強化にも役立ちます。

しかしながら、IaCのワークフローを標準化して整備したとしても、完璧ではありません。実際には組織の目標や不測の事態に応じて、インフラは変更および更新され続けます。インフの状態が変化し、コードで定義されたものと一致しない状態 (この現象を「ドリフト」と呼びます) になると、IaCの効率とセキュリティを損なう危険性があります。そのため、リソースのライフサイクル管理が重要になってきています。ここで鍵となるのがドリフト検出です。

IaCの価値を最大化するためには、インフラで起きるドリフトの原因、その影響 (特にセキュリティ) を理解し、問題の解決に役立つドリフトの検出と修復を実装するための最善の方法を理解することが重要です。
インフラが「ドリフト」してしまう原因

ドリフトが発生してしまう原因はいくつか考えられます。まず、組織内の全員が適切に確立された「IaCのワークフロー」を使用していない場合があります。全員が同じものを使用していないため、コードで定義されたインフラと実際の状態との間に違いが生じてしまう可能性があります。

もう1つの一般的な原因には、「緊急事態の対応」があります。何らかの不慮の事態が起きると、対応管理チームは問題をできるだけ早く修復しようとします。場合によっては時間短縮のために、インフラにパッチ適用する時の標準的な手順をバイパスすることもあるでしょう。こうした手順のショートカットで起きる変更は、コードを追跡して解決することを難しくさせる可能性があります。

さらに時間が経過するにつれ、クラウドまたはサービスプロバイダーのシステムや仕様が更新される可能性もあります。すなわち、インフラのルールとプロバイダーのシステムが徐々に乖離するにつれ、ドリフトは大きくなります。例えば、何らかのサービスプロバイダーがサードパーティー向けに提供しているAPIで考えてみると、些細な仕様変更だったとしても、インフラに影響を与える可能性があるのです。

また、カスケード効果により、ドリフト検出が複雑化する可能性もあります。例えば、新しいインフラのリソースを作成または変更する場合、予期せずコード化されていない関連リソースが生じてしまう可能性があります。リソースの状態を変更するようなカスケード効果により、誰も気付かないうちに相互に影響を及ぼします。
ドリフトがインフラのセキュリティと機能に与える影響

クラウドの採用が広がるにつれ、組織のリソースとプロセスはますます複雑になり、インフラの状態に矛盾が生じる可能性があります。もし、インフラを調整するための標準的な手順、通知、ガイドラインがなければ、一時的な変更やわずかな調整であったとしてもビジネスに致命的な影響を与えるリスクがあります。

例えば、計画外のダウンタイム、監査結果、セキュリティインシデント、やり直し、未使用のリソース（無駄な出費）などです。

最も重要なことは、インフラのドリフトでリスクが生じると、問題が発生しないように対処することです。例えば重要なシステムが誤ってパブリック環境に公開されていたり、リソースが保護されていないことに気づかず重要なデータが漏えいしたりするなど、このような致命的なリスクが劇的に高まる可能性があります。

さらに、開発チームが本番環境の変更を認識していないと、ほぼ確実にアプリケーションが「突然」クラッシュしたり、デプロイしたプロジェクトが予期せず失敗したりするなど、インシデントに直面することになります。

●
ドリフトの検出から修復まで

では、組織はどのようにドリフトの検出を処理すればいいのでしょうか？また、ドリフトが検出されたら状況を修復するために何をすればいいのでしょうか？

一部の企業では、ドリフトの発生状況を一度にチェックし、すべてのユーザーに電子メールでレポートを送信する社内ツールを構築しています。しかし、変更の背後にコンテキストがないため、「必要な変更」と「不必要な変更」を区別することが難しくなります。

また、リソースまたは記録されたIaCの状態を手動で変更する場合、ユーザーの手に委ねられます。すなわち、このアプローチでは拡張するのに時間がかかり過ぎてしまいます。

これらの課題を根本的に解決するためには、次の2つの重要な問いに帰着します。

記録されたインフラの状態が実際のインフラに反映されていることを確認し、検出されたドリフトに対して適切な担当者に是正措置を講じるよう通知するにはどうすればよいのでしょうか？
ドリフトを検出するためのソリューションは、IaCプラットフォームとシームレスに連携しながら、エンジニアリングチームとセキュリティチームの中心的な情報源となり、効率性とシンプルさを優先できていますか？

ドリフト検出の鍵は“一元化された可視性”

ドリフトに関心があるならば、統合された「ドリフト検出ソリューション」を探す必要があります。これは統合された環境で動作し、適切なチームに即座に通知できなくてはなりません。

理想としては、自動プロビジョニングと集中管理がオールインワンであり、インフラの状態を継続的に監視することで変更を検出できることです。これによりリソースが変更されたときに、いつでも開発チームが何らかの是正措置を講じることができます。

既知のリスクと、これまで検出できなかったインフラのドリフトで生じるリスク、これらがもたらすセキュリティのリスクに関心があるCISOにとって、このようなソリューションは運用上の負担を過度に増やすことなく、組織全体のセキュリティ体制を強化するのに役立ちます。

そして、ドリフト検出ソリューションを統合することで、ユーザーエクスペリエンス、ひいては収益に悪影響を及ぼしかねないアプリケーションのダウンタイムを大幅に削減できます。また、チームがシステム変更を追跡することで、誰がなぜ変更したかを特定し、後で参照できるようにそれらの変更を記録したり、必要に応じて標準のワークフローを調整したりすることもできます。

また、堅牢なドリフト検出ソリューションでは、チームが共同作業できる単一の信頼できる情報源を提供することで、運用の俊敏性を高めることができます。同じ情報に基づいた作業が可能となるため、カスタムツールの購入または開発、状態を更新する際に手動で操作する必要がなくなります。同時に可視性がもたらされ、解決までの時間が短縮できます。
インフラに必要なものは自動化、検出、アラート

インフラのプロビジョニングを自動化すると、生産性に大きなメリットをもたらします。しかし、インフラが変更され、実際の状態が記録や定義と乖離しているとどうでしょうか？

インフラで起きるドリフトの影響を最小限に抑えるには、運用チームに可視性と、必要に応じて適切な担当者に警告を発するドリフト検出ソリューションが必要です。一元化と自動化されたツールを使用すれば、標準化されたプロセスの中で体系的に連携することで、リスクを軽減し、システムの可視性を高め、チームがインフラの問題をより迅速に解決できるようになるのです。

著者プロフィール

花尾和成 HashiCorp Japan カントリーマネージャー

約20年間、日本企業の顧客インフラの近代化、経営管理／データ分析やクラウド技術の活用とそれらを利用したデジタルトランスフォーメーションの推進に尽力。日本ヒューレット・パッカード（現Hewlett Packard Enterprise）、日本オラクル、Pivotalジャパン、VMware日本法人などを経て、2020年11月から現職。