なぜインフラストラクチャに独自のポリシーが必要なのか
あなたのチームは堅牢なCI/CDパイプラインを持っている。アプリケーションのビルド、テスト、デプロイはスムーズに進み、1日に何度も変更をリリースできる自信がある。そんなある日、誰かがAWSのセキュリティグループを追加するプルリクエストを開く。アプリをインターネットからアクセス可能にする必要があるのだ。急いでいるため、ポート22を0.0.0.0/0に開放してしまう。すると今や世界中の誰もがあなたのサーバーにSSH接続を試みられるようになる。数分も経たないうちに、ボットがブルートフォース攻撃を仕掛け始める。
これは仮定の話ではない。ガードレールなしでインフラを管理している組織では、毎日起こっている現実だ。
アプリケーションのパイプラインは完璧かもしれない。しかし、アプリケーションは空気だけで動いているわけではない。サーバー、データベース、ロードバランサー、ネットワーク、ストレージの上で動作している。これらのリソースは作成、設定、保守が必要であり、アプリケーションコードとは根本的に異なるリスクを伴う。
インフラポリシーが解決する問題
実際のチームでよく見られるシナリオをいくつか見てみよう。
プレッシャーの中でセキュリティミスが発生する。 開発者がAPIエンドポイントを公開する必要がある。セキュリティグループルールを追加する。彼らの頭の中では、単にアプリを動かそうとしているだけだ。SSHを全世界に開放してしまったことに気づいていない。誰かが気づく頃には、サーバーはすでに侵害されているかもしれない。
コスト漏れは静かに、そして累積的に発生する。 エンジニアがテスト用にEC2インスタンスを立ち上げる。利用可能だったので、最大のインスタンスタイプを選ぶ。選択肢に制限はない。そのインスタンスは1週間誰にも気づかれずに稼働し続ける。月末のクラウド請求書が届くと、財務チームは予期せぬ急増を目にする。たった1つの忘れられたインスタンスが、本来別の用途に使われるべき予算を消費してしまったのだ。
命名の混乱が運用を困難にする。 どの企業にもリソース命名の規則がある。プロジェクトプレフィックス、環境、リージョンなどだ。しかし強制力がなければ、各自が好き勝手に名前をつける。別のチームがデバッグのためにリソースを探そうとしても、どれがどれだかわからない。自動化スクリプトがリソース名をパースするとき、フォーマットが不統一で壊れてしまう。
コンプライアンス違反は高くつく。 あなたの会社がPCI DSS、HIPAA、SOC 2に準拠する必要があるかもしれない。これらの基準はインフラに特定の制御を要求する。誰かが誤って承認されたリージョン外にリソースを作成したり、暗号化されていないバケットにデータを保存したりすると、罰金や認定資格の喪失につながる可能性がある。
トレーニングや標準運用手順だけでは、これらの問題を防ぐことはできない。人は間違いを犯すものだ。特に納期に追われているときはなおさらだ。必要なのは、違反が発生する前に自動的に検出する仕組みである。
インフラポリシーとは何か
インフラポリシーとは、インフラリソースを作成または変更する際に、何が許可され、何が禁止されているかを定義する一連のルールである。これらのルールは壁に貼られた文書ではない。機械可読であり、パイプラインで自動的にチェックされ、変更を加える開発者に直接フィードバックを返す。
ガードレールのようなものだと考えてほしい。ガードレールは運転を止めさせるものではない。道路に留まらせ、崖から落ちる心配をせずに速く運転できるようにする。優れたインフラポリシーも同じように機能する。安全な境界がわかっているため、チームは迅速に動ける。ミスを犯すことを恐れる必要はない。なぜなら、ミスが本番環境に到達する前にポリシーが警告してくれるからだ。
アプリケーションポリシーだけでは不十分な理由
アプリケーションコードに対してすでにポリシーを持っているかもしれない。リンタールール、コードレビュー要件、テストカバレッジのしきい値などだ。これらは重要だが、インフラをカバーしてはいない。
アプリケーションコードとインフラでは、リスクプロファイルが異なる。
- アプリケーションのバグは通常、ユーザーに影響する。機能が壊れる。エラーが発生する。データが破損する。
- インフラのミスはより広範囲に影響する。クラウドコストが爆発する。ポートが公開される。データが漏洩する。リソースがコンプライアンスルールに違反する。
影響は技術的なものだけではない。財務的、法的な影響もある。たった1つの誤設定されたS3バケットが顧客データを流出させ、規制上の罰金を引き起こす可能性がある。たった1つの過剰プロビジョニングされたインスタンスが、月に数千ドルを無駄にする可能性がある。
インフラポリシーはこれらのリスクに直接対処する。セキュリティの誤設定、コスト違反、命名規則、タグ付け要件、コンプライアンスルールをチェックする。変更が適用される前に、インフラパイプラインの一部として実行される。
ポリシーをワークフローに組み込む方法
インフラポリシーを強制する最も効果的な方法は、CI/CDパイプラインを通じて行うことだ。誰かがインフラコードを変更するプルリクエストを開くと、パイプラインは通常のテストと並行してポリシーチェックを実行する。ポリシーに違反している場合、パイプラインは失敗する。開発者は、どのルールが破られ、どのように修正すればよいかを説明する明確なメッセージを受け取る。
以下の図は、ポリシーチェックが典型的なインフラパイプラインにどのように統合されるかを示している。
このアプローチにはいくつかの利点がある。
- 早期フィードバック。 開発者は変更が本番環境に到達する前に問題を把握できる。
- 一貫した強制。 すべての変更が同じチェックを受ける。例外はない。
- 監査可能な証跡。 どの変更がポリシーチェックに合格または不合格になったかを確認できる。
- 段階的な導入。 重要なポリシーから始めて、徐々に拡大できる。
ポリシーによって開発が遅くなるのではと心配するチームもいる。実際には逆のことが起こる。チームは境界がわかっているため、より速く動ける。「これは許可されているのか？」と立ち止まって尋ねたり、セキュリティレビューを待ったりする必要がない。ポリシーがそれらの質問に自動的に答えてくれる。
始めるための実践的なチェックリスト
インフラポリシーが初めてなら、以下の短いリストが役立つだろう。
- セキュリティから始める。 パブリックなSSH、RDP、データベースポートをブロックする。保存データと転送中のデータの暗号化を要求する。IAM権限を最小権限に制限する。
- コスト管理を追加する。 許可されるインスタンスタイプを制限する。最大リソースサイズを設定する。非本番環境リソースには自動停止を要求する。
- 命名規則とタグ付けを強制する。 一貫性のあるリソース名を要求する。所有者、環境、コストセンターのタグを必須にする。
- コンプライアンスルールをチェックする。 許可されるリージョンを制限する。特定の暗号化設定を要求する。規制基準に違反するリソースをブロックする。
- パイプラインに統合する。 すべてのプルリクエストでポリシーチェックを実行する。違反があった場合はビルドを失敗させる。明確なエラーメッセージを提供する。
最も重要なポリシーから始めよう。チームが慣れてきたら、さらに追加していく。目標は、あらゆるミスを防ぐことではない。最も大きな損害を引き起こすミスを防ぐことだ。
具体的な要点
アプリケーションパイプラインは話の半分に過ぎない。アプリケーションを実行するインフラストラクチャには、独自の自動化されたガードレールが必要だ。それがなければ、たった1つの誤設定されたリソースがコストを発生させ、データを流出させ、コンプライアンス違反を引き起こす可能性がある。インフラポリシーは、それらのリスクを自動チェックに変え、問題が発生する前に捕捉する。セキュリティとコストから始めよう。命名規則とコンプライアンスを追加し、パイプラインに統合する。境界が安全だとわかっていれば、チームはより速く動けるようになる。