執筆者: Filippo Seracini (Program Manager)
このポストは、8 月 23 日に投稿された Security and Compliance in Azure Stack の翻訳です。
Azure Stack のセキュリティ ポスチャとコンプライアンス検証のロードマップ
プライベート クラウドやハイブリッド クラウドでインフラストラクチャを管理しながら、IaaS や PaaS によるアプリケーションの刷新を進めようとする場合、セキュリティの考慮事項やコンプライアンス規定が重要になります。Azure Stack はこのようなシナリオ向けに、セキュリティとコンプライアンスを重視して設計されています。
Azure Stack の実装を開始する前に、マイクロソフトはソリューションのセキュリティに関して期待することをお客様に伺いました。予想どおり、ほとんどのお客様が、認証済みの独自のセキュリティ機能が既定で強化されているソリューションを求めていることが明らかになりました。また、コンプライアンス関連の面倒な事務処理に関する悩みも寄せられました。
このようなご意見を参考に Azure Stack を実装しました。
この記事では、Azure Stack インフラストラクチャのセキュリティ ポスチャの概要と、フィードバックへの対応内容をご紹介します。また、コンプライアンス認定プロセスの迅速化や事務手続きの簡略化に対する取り組みについてもお伝えします。
セキュリティ ポスチャ
Azure Stack のセキュリティ ポスチャは、以下の 2 つの原則に基づいています。
- 侵害を想定した対応
- 既定での強化
侵害を想定した対応 (英語) は最新のセキュリティ アプローチで、侵入の防止だけでなく、侵入時の検出と拡散阻止にも重点を置いています。つまり、未然に防ぐというアプローチだけでなく、堅牢な検出機能の実装に積極的に取り組むということです。これにより、一部のコンポーネントが侵害を受けた場合でも、システム全体に直接的な影響が及ぶことはありません。
攻撃を受ける頻度が最も高いのは、さまざまな特権アクセスが関連付けられた管理者ロールです。マイクロソフトは、侵害想定の原則に基づいて、定義済みの制限付き管理者エクスペリエンスを作成しました。これにより、管理者の資格情報が侵害を受けた場合に、攻撃者がインフラストラクチャ内のすべてのコンポーネントに無制限にアクセスすることを防ぎ、システムで設定した以外の操作を行えないようにします。また、同じ原則に基づいて、Azure Stack ではユーザーがアクセスできるドメイン管理者アカウントを廃止しました。管理者ロールをさらに細分化したい場合は、非常にきめ細かなロール ベースのアクセス制御 (RBAC) を利用して、各ロールの機能を完全に制御することができます。
Azure Stack インフラストラクチャは、アクセス許可 (ログイン可能なアカウントを完全に排除1) とネットワークの 2 つの観点で完全に保護されており、認証を受けていないユーザーが侵入するのは非常に困難です。インフラストラクチャでは複数のレベルでネットワーク アクセス制御リスト (ACL) が適用されており、不審な受信トラフィックやインフラストラクチャ コンポーネント間の不要な通信はすべて遮断されます。ACL のポリシーはきわめてシンプルで、必要でないものはすべて遮断するように定められています。
検出機能を大幅に強化するために、各インフラストラクチャ コンポーネントのセキュリティおよび監査ログは、ストレージ アカウントで一元的に保管されます。このログは、インフラストラクチャの状態を詳細に把握したり、(セキュリティ情報/イベント管理などの) 各種セキュリティ ソリューションで監視したりする際に活用されます。
Azure Stack のハードウェアとソフトウェアの構成の定義については、既定での強化という原則に従い、ハードウェアは設計時点で既に強化されています。Microsoft SDL (英語) と同じく業界のベスト プラクティスに準拠しているほか、Azure Stack ではインフラストラクチャとテナント データの両方が格納時にも暗号化され、インフラストラクチャ ネットワークの通信中の暗号化には TLS 1.2 が適用されます。さらに、Kerberos に基づくインフラストラクチャ コンポーネント認証、軍用レベルの OS セキュリティ基準 (DISA STIG に準拠)、内部シークレットの自動ローテーション、古いプロトコル (NTLM や SMBv1 など) の無効化、セキュア ブート、UEFI、TPM 2.0 などにも対応しています。このほか、Credential Guard (Pass-the-Hash 攻撃からの資格情報の保護) やデバイス ガード (ソフトウェアのホワイトリスト)、Windows Defender (マルウェア対策) などの Windows Server 2016 のセキュリティ機能も有効化されています。
セキュリティ ポスチャには、堅牢で継続的なサービス プロセスが不可欠です。そのため、Azure Stack では、インフラストラクチャ全体にシームレスに修正プログラムや更新プログラムを適用する、オーケストレーション エンジンを重視した設計となっています。
OEM パートナーとの緊密な連携により、Azure Stack と同じセキュリティ ポスチャが、Hardware Lifecycle Host などの OEM 独自のコンポーネントとソフトウェアにも適用されます。このため、Azure Stack では、一貫した堅牢なセキュリティ ポスチャが適用されたインフラストラクチャ上で、アプリケーションを安全に構築して運用できます。
さらに安全性を高めるために、2 社の外部ベンダーによる OEM 独自のコンポーネントを含む統合システム全体の広範な侵入テストを実施しています。
Azure Stack のデプロイにおいては、サードパーティのセキュリティ ソフトウェアによる保護の強化も可能です。主要なセキュリティ企業と連携して、各社のソフトウェアが相互運用できることを確認しています。Azure Stack と連携したいソフトウェアがありましたら、こちらのアンケート (英語) でお知らせください。
規制遵守
コンプライアンス関連の事務処理が非常に面倒であるというご意見を多くお寄せいただきました。この問題の解決に向けて、Azure Stack は第三者評価機関による正式な評価を進めています。この結果は、Azure Stack のインフラストラクチャが主要コンプライアンス標準に準拠していることを証明するドキュメントとして、認定手続きの迅速な処理に活用できるようになります。現在 PCI-DSS (英語) と CSA Cloud Control Matrix (英語) の評価が進められています。PCI-DSS はクレジット カード業界のセキュリティ基準で、CSA-CCM はさまざまな標準を包括的にマッピングするものです。
さらに、Azure Stack の Common Criteria (英語) 認定の手続きも開始しました。手続きには少々時間がかかりますが、来年上旬に完了する予定です。
Azure Stack に関して、マイクロソフトが認定を受ける標準は Common Criteria のみとなります。理由としては、このような標準はユーザーやプロセスに関する内容を含んでおり、お客様が個別に対応する必要があるためです。現在、Azure Stack が適切な基準を満たしているか、正式な検証を実施しています。第三者評価機関による検証結果は、準拠を証明するコンパイル済みのドキュメントとしてマイクロソフトが公開します。
今後数か月間で、Azure Stack は検証する標準の範囲を拡大していきます。検証実施の順序はお客様のご要望に応じて決定されます。優先度に関するご要望がありましたら、こちらのアンケート (英語) でお知らせください。
参照情報
フロリダ州オーランドで開催される Microsoft Ignite 2017 に参加予定のお客様は、チーフ アーキテクトの Jeffrey Snover と筆者が担当する Azure Stack のセキュリティとコンプライアンスに関するセッションにぜひご参加ください。
Azure Stack チームは、お客様の声を重視しており、新しいお客様との出会いの場を大切にしています。ハイブリッド クラウドに強い関心をお持ちでしたら、ぜひ Ignite にご参加いただき、Azure Stack の構築に関してチームと直接意見を交わしてください。こちらから登録 (英語) していただけます。
1PowerShell JEA エンドポイントからの一部の定義済みアクセス許可による操作を除く