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