セキュリティルールがドキュメントの中にあると無視される

セキュリティチームが数週間かけてコンテナイメージスキャンポリシーを策定したとします。メールで送付し、全体会議でアナウンスし、社内Wikiに保存しました。3ヶ月後、誰かが本番パイプラインを確認すると、スキャンが一度も有効化されていないことが判明します。あるプロジェクトで設定が欠落していたのですが、誰も気づきませんでした。

これは悪意のある話ではありません。ルールがパイプラインの外側にあると、どうしても守られなくなるという話です。

ドキュメントとしてのルールの問題点

文書化されたポリシーには根本的な弱点があります。それは、人間が読んで、覚えて、正しく適用することに依存している点です。チームごとに同じルールの解釈が異なります。プロジェクトごとに設定のクセがあります。ルールが変更された場合、誰かが該当するすべての場所を手動で更新し、さらに別の誰かが更新が実際に行われたことを確認する必要があります。

結果は予測可能です。あるチームはルールを守り、別のチームは少し異なるバージョンを適用し、さらに別のチームは完全に忘れてしまいます。そして、何か問題が発生するまで、どの状況が起きているのか誰も知りません。

これら2つのアプローチの違いは、フローを図にすると明確になります。

これは人の問題ではありません。デリバリーの問題です。ルールがソフトウェアをデリバリーするシステムの一部になっていないのです。ルールはシステムの外側にあり、人間がアクションに変換する必要があるテキストとして存在しています。

ルールをコードとして書く

ポリシーアズコードは、ルールのデリバリーモデルを変えます。ポリシーをドキュメントに書く代わりに、機械が読み取れる形式で書き、リポジトリに保存し、パイプラインの一部として実行します。アプリケーションコードを扱うのと同じワークフローで、セキュリティルールとコンプライアンスルールを扱えるようになります。

形式はさまざまです。Open Policy AgentのRegoを使うチームもいれば、定義されたスキーマを持つYAMLを使うチームもいます。既存のスキャンツールに組み込まれているポリシーフレームワークを使うチームもいます。言語よりも重要なのは原則です。ルールが書き、バージョン管理され、レビューされ、自動的に実行されることです。

簡単なルールを考えてみましょう。コンテナはrootとして実行してはいけません。ポリシーアズコードでは、これはポリシーエンジンが評価できる明確なステートメントになります。パイプラインはデプロイ前にすべてのコンテナイメージに対してエンジンを実行します。イメージがrootで実行される場合、パイプラインは停止します。ルールを変更する必要がある場合、誰かがポリシーファイルを編集し、プルリクエストを作成し、レビューを待ちます。変更は他のコード変更と同じプロセスを経ます。

ルールがコードになると何が変わるか

最初のメリットは一貫性です。同じルールがすべてのプロジェクト、すべてのパイプライン、すべてのデプロイに対して実行されます。誰かがスキャンを有効にするのを忘れたり、2つのチームが同じツールを異なる方法で設定したりするギャップはありません。新しいルールが追加されると、すべてのパイプラインが自動的にそれを取得します。

2つ目のメリットはテスト容易性です。ポリシーアズコード以前は、新しいルールが正しいことをどうやって確認していましたか？本番パイプラインでテストするのはリスクが伴います。あるいは、テストを完全にスキップして、うまくいくことを願うかもしれません。ポリシーアズコードでは、ルールに対するテストを書きます。rootユーザーのコンテナがポリシーに違反するテストケースと、非rootコンテナがパスするテストケースを作成します。これらのテストはユニットテストと同じようにCIで実行されます。誰かがルールを変更してロジックを壊した場合、ルールが本番に到達する前にテストがそれをキャッチします。

3つ目のメリットは監査可能性です。すべてのルール変更はバージョン管理に記録されます。誰が、いつ、なぜ、何を変更したかを確認できます。悪いルール変更は、悪いコード変更をロールバックするのと同じ方法でロールバックできます。監査人がコンテナがrootで実行されているかどうかを尋ねてきたら、最新ではないかもしれないドキュメントではなく、ポリシーファイルとパイプラインログを指し示します。

すべてをゼロから書く必要はない

よくある誤解は、ポリシーアズコードはすべてのルールを自分で書くことを意味するというものです。実際には、ほとんどのルールは既存のフレームワークから来ています。セキュリティツールには、CISベンチマーク、規制フレームワーク、一般的なセキュリティパターン用のポリシーが同梱されています。組織に適用されるものを有効にし、リスク許容度に合わせてしきい値を調整します。

ゼロから書くのは、通常、組織固有のものです。特定のクラウドリージョンへのデプロイを禁止する場合や、すべてのリソースに特定のラベルセットが必要な場合、本番デプロイに2番目の署名が必要な場合などです。これらは既存のフレームワークではカバーされないルールであり、コードとして書くことで最も恩恵を受けるルールです。

実践的なシフト

ポリシーアズコードは、セキュリティチームとエンジニアリングチームの関係を変えます。セキュリティはもはやルールを壁の向こうに送り、実装されることを願うだけではありません。セキュリティはルールをコードとして書き、アプリケーションコードと同じレビュープロセスを通じて提出し、すべてのパイプライン実行で結果を確認します。

エンジニアリングチームは、ルールに従っているかどうかを推測する必要がなくなります。パイプラインがすぐに教えてくれます。変更がポリシーに違反する場合、ビルドは明確なメッセージとともに失敗します。チームは問題が本番に到達する前に修正します。6ヶ月後に監査で発見されてから修正するのではありません。

始めるためのクイックチェックリスト

• 現在ドキュメント化されているが、頻繁に違反されているルールを1つ選ぶ。
• そのルールを、既存のセキュリティツールのポリシーフレームワークを使ってコードとして書く。
• CIパイプラインにポリシーチェックを追加する。
• ルールが違反をキャッチすることを証明するテストを書く。
• ルールが準拠した変更を許可することを証明する別のテストを書く。
• 古いドキュメントを削除し、代わりにポリシーファイルを参照するようにする。

1つのルールから始めてください。ワークフローが機能することを証明してください。そして拡大してください。

まとめ

ドキュメントの中にあるルールは無視されるルールです。パイプラインの中にあるルールは強制されるルールです。ポリシーアズコードは、より多くのルールを書くことではありません。すでにあるルールを、毎回、すべての変更に対して、誰かがメールを読むのを覚えていることに依存せずに、実際に機能させることです。