Microsoft Azure のような複雑なシステムを運用するうえでの大きな課題は、承認されたソフトウェアだけがシステムで実行されるようにすることです。 承認されていないソフトウェアは、ビジネスに対していくつかのリスクをもたらします。
- 専用の攻撃ツール、カスタム マルウェア、既知の脆弱性を持つサードパーティ製のソフトウェアなどのセキュリティ リスク
- 承認された変更管理プロセスを使わずに新しいソフトウェアが導入される場合のコンプライアンス リスク
- 外部開発のソフトウェアによる品質リスクは、ビジネスの運用要件を満たさない可能性があります
Azureも同様の課題に直面しており、非常に複雑な問題を抱えています。 数千台のサーバーがソフトウェアを動かし、そのソフトウェアは何千人ものエンジニアが開発・維持しています。 この規模は、ビジネスプロセスだけでは管理できない大きな攻撃面をもたらします。
承認ゲートの追加
Azureは、展開されたソフトウェアのセキュリティ、コンプライアンス、品質に関するゲートを実装する豊富なエンジニアリングプロセスを用いています。 このプロセスには、ソースコードへのアクセス管理、ピアコードレビュー、セキュリティ脆弱性の静的分析、Microsoftのセキュリティ開発ライフサイクル(SDL)、機能および品質テストが含まれます。 Microsoftは、導入されたソフトウェアがこのプロセスを通過することを保証する必要があります。 コードの完全性はその保証の実現に役立ちます。
承認ゲートとしてのコードの整合性
コード整合性は、Windows Server 2016から利用可能になったカーネルレベルのサービスです。 ドライバーまたはダイナミック リンク ライブラリ (DLL) の読み込み、実行可能バイナリの実行、またはスクリプトの実行のたびに、コードの整合性によって厳密な実行制御ポリシーを適用できます。 Linux 用には、DM-Verity などの同様のシステムが存在します。 コード整合性ポリシーは、コード署名証明書または SHA-256 ファイルハッシュのいずれかの認可インジケーターのセットで構成されており、カーネルはバイナリやスクリプトの読み込みや実行前にこれにマッチングします。
コードの整合性により、システム管理者は特定の証明書が署名するバイナリやスクリプトのみを承認するポリシーを定義できます。これは特定のSHA-256ハッシュに一致するものです。 カーネルにおいては、設定されたポリシーを満たしていないあらゆるものの実行をブロックすることで、このポリシーが適用されます。
コード整合性ポリシーは、ポリシーが完全に正しくなければ、本番環境で重要なソフトウェアをブロックし、障害を引き起こすことがあります。 この懸念を踏まえ、なぜセキュリティ監視だけでは不正なソフトウェア実行を検出できないのか疑問に思うかもしれません。 コード整合性には監査モードがあり、実行を阻止する代わりに、不正なソフトウェアが実行された際に警告を発します。 アラートはコンプライアンスリスクへの対応に大きな価値をもたらします。 しかし、ランサムウェアやカスタムマルウェアのようなセキュリティリスクでは、対応を数秒遅らせるだけで、防御と敵対者があなたの艦隊に根付くかどうかの違いになることがあります。 Azureでは、Microsoftはコードの完全性が顧客に影響を与える障害のリスクを管理するために多大な投資を行っています。
ビルドプロセス
前述の通り、Azureビルドシステムはソフトウェア変更が安全かつ準拠であることを保証するための豊富なテストセットを備えています。 ビルドが検証を経た後、ビルドシステムはAzureビルド証明書を使って署名します。 証明書はビルドが変更管理プロセス全体を通過したことを示します。 ビルドが最後に通過するテストはコード署名検証(CSV)です。 CSVは、Microsoftが本番環境にデプロイする前に、新たに構築されたバイナリがコード整合性ポリシーを満たしていることを確認しています。 この検証により、誤った署名のバイナリが顧客に影響を及ぼす障害を引き起こすことはないというMicrosoftの強い確信がもたらされます。 CSVが問題を見つけた場合、ビルドは壊れ、関係エンジニアが調査と修正のために呼ばれます。
デプロイ中の安全性
AzureはすべてのビルドでCSVを実行していますが、本番環境の変更や不整合がコード整合性に関する障害を引き起こす可能性があります。 例えば、マシンが古いバージョンのコード整合性ポリシーを実行している場合や、コード整合性に誤検知が生じる不健康な状態にある場合もあります。 Azureの規模では、Microsoftはあらゆる面を経験しています。 Azureは展開中の障害リスクから引き続き保護しています。
Azureのすべての変更は一連の段階を経て展開しなければなりません。 最初の段階は内部Azureテストインスタンスです。 次の段階は他のMicrosoft製品チームのみを対象とします。 最後の段階では、サードパーティの顧客にサービスを提供します。 Azureが変更を展開すると、変更は順に各段階に移動し、ステージの健全性を測定するために一時停止します。 変更が悪影響を及ぼさなければ、次の段階に進みます。 もしMicrosoftがコード整合性ポリシーに誤った変更を加えた場合、段階的な展開はその変更を検出しロールバックします。
インシデント対応
このような多層的な保護があっても、フリート内のサーバーが適切に認可されたソフトウェアをブロックし、顧客対応の問題を引き起こす可能性があり、これはMicrosoftにとって最悪のシナリオの一つです。 最後の防御層は人間の調査です。 コードの整合性によってファイルがブロックされるたびに、アラートが生成され、待機しているエンジニアが調査します。 このアラートにより、エンジニアはセキュリティ調査を開始し、問題が実際の攻撃の兆候であれ、誤検知であれ、顧客に影響を与える他の状況であれ、介入することができます。 このアラートはコードの整合性に関する問題を軽減するのにかかる時間を最小限に抑えます。
次のステップ
Microsoftがどのようにプラットフォームの整合性とセキュリティを推進しているかについては、以下をご覧ください: