クラウドでコストとセキュリティを無駄にしないための5つのインフラポリシー
ある開発者が、本番サーバーにSSHでアクセスして簡単なデバッグを行いたいと考えました。自宅のIPから接続できるようにするため、ポート22を0.0.0.0/0に開放します。デバッグは終了し、チケットはクローズされますが、そのセキュリティグループルールは3ヶ月間そのまま残りました。誰も気づかず、クラウドの請求書が届いて初めて驚くことになります。開発アカウントでm5.24xlargeインスタンスが誰かによって起動され、24時間365日稼働し、タグもなく、名前はtest123だったのです。
これは仮定の話ではありません。このパターンは、四半期ごとにさまざまなチームで繰り返し発生しています。解決策は、手動レビューを増やしたり、アクセス制御を厳格にしたりすることではありません。解決策は、コードとして記述されたポリシーであり、リソースが作成される前に自動的にチェックされることです。
インフラストラクチャポリシーは5つのカテゴリに分類されます。それぞれが特定のクラスの問題を解決します。これらを理解することで、パイプラインでどのポリシーを優先すべきかを判断するのに役立ちます。
セキュリティ:譲れないベースライン
セキュリティポリシーは、違反が即座に目に見える結果をもたらすため、最も重要です。典型的な例は、SSHやデータベースのポートを0.0.0.0/0に開放するセキュリティグループルールをブロックすることです。開発者は一時的なアクセスのためにこれらを開放し、閉じるのを忘れることがよくあります。パイプラインの時点でこのようなルールを拒否するポリシーは、本番リソースが誤ってインターネットに公開されるのを防ぎます。
その他の一般的なセキュリティポリシーは次のとおりです。
- S3バケットとEBSボリュームの保存時の暗号化を必須にする
- ロードバランサーでの古いTLSバージョンをブロックする
- すべてのパブリックエンドポイントでHTTPSのみのトラフィックを強制する
- 本番環境でのVPCフローログを必須にする
- 長期有効なアクセスキーではなく、IAMロールを必須にする
セキュリティポリシーは通常、ハードフェイル(厳格な失敗)動作をします。チェックに失敗した場合、パイプラインは停止し、リソースは作成されません。インターネット全体に開放されたポートに対して、警告モードは存在しません。
コスト:偶発的な予算超過を防ぐ
クラウドリソースは、放置しておくと高額になります。一人の開発者が、チームメンバーの月収に相当するインスタンスタイプを誤ってプロビジョニングする可能性があります。コストポリシーは、すべてのリソースに手動承認を必要とせずに、支出にガードレールを設定します。
典型的なコスポリシーは次のとおりです。
- 非本番環境での高額なインスタンスタイプ(
m5.24xlargeやr5.metalなど)をブロックする - アカウントあたりのEBSボリュームまたはGPUの数を制限する
- フォールトトレラントなワークロードにはスポットインスタンスを必須にする
- データベースの最大ストレージサイズを設定する
- 開発環境の自動停止スケジュールを強制する
コストポリシーは、特に多くの開発者がクラウドアクセスを持っている場合に、チームが予算を意識するのに役立ちます。これらがなければ、一人の都合がチームへの驚きの請求書になる可能性があります。
タグ付け:運用を支えるメタデータ
タグ付けは、6ヶ月間稼働しているリソースの所有者を特定する必要が生じるまでは、退屈に聞こえるかもしれません。owner、environment、cost-center、projectなどのタグは、コスト追跡、クリーンアップの自動化、インシデントのデバッグに不可欠です。
タグ付けポリシーは、すべてのリソースが作成時に必要なタグを持つことを強制します。例えば:
- すべてのリソースは、有効なメールアドレスを持つ
ownerタグを持たなければならない - すべてのリソースは、
dev、staging、productionのいずれかのenvironmentタグを持たなければならない - すべてのリソースは、チームの予算コードに一致する
cost-centerタグを持たなければならない
リソースがタグ付けポリシーに違反した場合、パイプラインはそれを拒否するか、警告とともに作成してクリーンアップをスケジュールすることができます。重要なのは、タグ付けされていないリソースが静的に蓄積されないことです。タグ付けポリシーは、請求チームが何ヶ月も稼働しているが明確な所有者がいない謎のリソースを発見するという「孤児リソース」問題を防ぎます。
命名規則:人間と自動化のための一貫性
リソース名は、ほとんどのチームが認識している以上に重要です。test123という名前のバケットとdata-barangという名前の別のバケットは、検索が難しく、自動化が難しく、トラブルシューティングも困難です。命名ポリシーは一貫したパターンを強制し、運用チームと自動化ツールがリソースを迅速に見つけられるようにします。
一般的な命名ポリシーは次のとおりです。
- すべてのS3バケットはプロジェクト名で始まる必要がある
- すべてのセキュリティグループは環境を示すプレフィックスを持つ必要がある
- すべてのRDSインスタンスは
{project}-{env}-{function}のパターンに従う必要がある - すべてのIAMロールにはサービス名と権限レベルを含める必要がある
命名ポリシーは、タグ付けポリシーと組み合わせられることがよくあります。これらを組み合わせることで、すべてのリソースが識別可能、検索可能、かつスケーラブルに管理可能であることが保証されます。これらがなければ、クラウドアカウントはガラクタ箱のようになってしまいます。
コンプライアンス:外部ルールをコードに変換する
コンプライアンスポリシーは、PCI DSS、HIPAA、SOC 2、GDPRなどの外部規制からの要件を処理します。これらはオプションではありません。法的および規制上の要件を、リソースがデプロイされる前に実行される自動チェックに変換します。
コンプライアンスポリシーの例:
- すべての本番データベースは保存時の暗号化を使用する必要がある
- 本番リソースへのすべてのアクセスは中央の監査証跡に記録される必要がある
- すべてのデータは承認された地理的リージョンに保存される必要がある
- すべてのバックアップは暗号化され、別のアカウントに保存される必要がある
- すべてのAPIアクセスは多要素認証を使用する必要がある
コンプライアンスポリシーは、エンジニアリングチームの外部から来るため、交渉が最も難しいことがよくあります。しかし、それらをコードとしてエンコードすることで、一貫性があり、監査可能で、手動のチェックリストよりもはるかに強制力が高まります。
これらのポリシーがどのように相互作用するか
これら5つのカテゴリは、独立して動作するわけではありません。単一のEC2インスタンスは、セキュリティグループルール、インスタンスタイプ、タグ、命名パターン、コンプライアンス要件など、複数のポリシーに対して同時にチェックされます。優れたパイプラインは、リソースが作成される前(後ではなく)にこれらすべてのチェックを実行します。
次の図は、5つのポリシーカテゴリが互いに、そしてデプロイパイプラインとどのように関連しているかを示しています。
順序も重要です。セキュリティとコンプライアンスのチェックは、これらのカテゴリの違反は譲れないため、最初に実行する必要があります。コストとタグ付けのチェックはその後で実行できます。命名チェックは通常、最も重要度は低いですが、運用の健全性のために強制する価値はあります。
始めるための実践的なチェックリスト
インフラストラクチャポリシーが初めての場合は、小さく始めてください。1つのカテゴリを選び、1つのチェックを自動化します。ほとんどのチームで機能する順序は次のとおりです。
- 1週目: パブリックSSHアクセスをブロックするセキュリティポリシーを追加します。パイプラインをハードフェイルにします。
- 2週目:
ownerタグとenvironmentタグを必須とするタグ付けポリシーを追加します。最初は警告から始め、2週間後にハードフェイルに移行します。 - 3週目: 開発アカウントで高額なインスタンスタイプをブロックするコストポリシーを追加します。違反時は警告し、チームリーダーにエスカレーションします。
- 4週目: アカウント内で最も一般的なリソースタイプに命名規則を追加します。
- 2ヶ月目: コンプライアンス要件を確認し、上位3つを自動チェックとしてエンコードします。
目標は、すべてのポリシーを一度に作成することではありません。目標は、最も痛みを伴う問題を最初に解決することで勢いをつけることです。
最も重要なこと
セキュリティポリシーとコンプライアンスポリシーは、外部の脅威や法的なエクスポージャーからあなたを守ります。コストポリシーは予算を守ります。タグ付けポリシーと命名ポリシーは、運用の健全性を守ります。これら5つのカテゴリすべてが連携して、インフラストラクチャ管理を手動でエラーが発生しやすいプロセスから、自動化された一貫性のあるプロセスに変えます。
今日最も問題となっているポリシーから始めてください。ほとんどのチームにとって、それはインターネットに広く開放されたセキュリティグループか、請求額を押し上げている謎のリソースのいずれかです。そのチェックを自動化し、次に進みます。時間の経過とともに、パイプラインはミスがインシデントになる前にそれをキャッチするセーフティネットになります。