Azure Stack Hub のセキュリティ
azurestack
Published: 2018-12-11
  • 初版:2018年12月
  • 第二版:2019年12月
  • 第二版:2022年3月

はじめに

本エントリーはMicrosoft Azure Stack Advent Calendar 2018の11日目です。

本日のエントリーでは、Azure Stack Hub のセキュリティについてまとめます。主な参照先は公式ドキュメントと Microsoft Ingnite 2018 における Filippo Seracini 氏のセッションです。

参考:Discovering the Importance of Security Design Principles and Key Use cases for Azure - BRK2305

ビジョン

Microsoft が描く Azure Stack Hub のセキュリティに対するビジョンは次の通りです。Microsoft は、「Microsoft の管理下ではない環境で動くAzure Stack Hub であっても、Azure と同レベルのセキュリティと保護をお客様に提供する」という凄いことをやろうとしています。

Internals are internal

このビジョンを実現するための基本的な考え方が「Internals are internal」です。Azure Stack Hub は Windows Server 2019 の機能を利用しています。ただし、Windows Server の部分を管理者にオープンにしてしまうと、次のようなリスクが生まれます。

  • 管理者が勝手にセキュリティに関する設定を変更してしまう
  • 悪意ある第三者に乗っ取られた管理者によって、セキュリティインシデントを起こされてしまう

つまり、高度なセキュリティの設定を組み込んで出荷したとしても、意味がなくなってしまうわけです。そこで、Microsoft は、「Azure Stack Hub の管理者に内部を自由に操作させない」という方針をとりました。Microsoft はセキュリティを確保するために、性悪説にもとづいてシステムを設計しているわけです。

そのため、自分のお金で買ったハードウェア上で動いている Windows Server ベースの製品にも関わらず、Azure Stack Hub の Infrastructure Role Instance にはリモートデスクトップで接続できませんし、必要に応じて自分の好きな設定を追加することもできません。すべてはビジョンを実現するためです。

制限付き管理者

Internals are internal の実装の1つが制限付き管理者です。

性悪説にのっとっているのですから、管理者になんでもできる特権管理者(Domain Admin)を与えるわけにはいきません。しかし、権限を全く与えないと、Azure Stack Hub の運用に支障をきたします。必要最低限の権限だけを管理者に付与する必要があります。

原則として、管理者は Azure Stack Hub を API 経由で操作します。管理者向けポータルや PowerShell などのツールは裏で API を呼んでいます。この時点で、管理者が実施できる作業は、API に実装されている操作のみです。管理者はハードウェアや OS を自由に操作できません。

API で Azure Stack Hub を操作できない時のため用意されている Emergency Recovery Console についても、権限の制限が徹底しています。Microsoft は Emergency Recovery Console 上に Privileged Endpoint(PEP) という仕組みを導入しています。PEP とは、PowerShell の Just Enough Administrator によって保護された PowerShell です。JEA を使うことで、Microsoft は「特権管理者の権限を有しているが、Microsoft が運用上使うである考えた数十個のコマンドのみを実行できる PowerShell 環境」を実現しています。

JEA を利用していない PowerShell では約4100個のコマンドを実行できます。つまり、管理者は、PowerShell でハードウェアや OS を自由に操作できます。

PS D:\Users\kongou-ae\Documents> $normalCommand = Get-Command
PS D:\Users\kongou-ae\Documents> $normalCommand.Length
4072

一方で、JEA で保護された PEP では約50個のコマンドだけを実行できます。利用できるコマンドの多くは、Azure Stack Hub 用に作られたものばかりです。したがって、管理者は PowerShell でハードウェアや OS を自由に操作できません。

PS D:\Users\kongou-ae\Documents> $pep = New-PSSession -ComputerName azs-ercs01 -ConfigurationName privilegedendpoint
PS D:\Users\kongou-ae\Documents> $commands = Invoke-Command -Session $pep { get-command }
PS D:\Users\kongou-ae\Documents> $commands.Length
49

API と PowerShell のどちらであっても ハードウェアと OS を自由に操作できない管理者は、もはや管理者ではありません。Microsoft は、Azure Stack Hub を運用管理する人を “Azure Stack Hub Operator” と呼んでいます。“Azure Stack Hub Administrator” ではありません。

ハードウェア周りの実装

Azure Stack Hub を構成するサーバでも、セキュリティを向上するためのハードウェア機能が利用されています。使える機能をしっかりと使っているという形ですね。詳しくないのでさらっと!

  • Secure Boot
  • UEFI
  • TPM 2.0

攻撃を受ける場所を減らす

攻撃を受けるリスクを減らす方法の一つが、攻撃を受ける場所を減らすことです。脆弱な場所があるから攻撃を受けるわけです。Azure Stack Hub では次のような実装がデフォルトでなされています。自分でやろうとすると地味に大変ですよね。

  • アメリカ国防情報システム局の Hardened security OS baseline に基づいた OS のベースライン設定
  • 不要なコンポーネントの削除
  • Windows Server のセキュリティ機能
    • Device Guard
    • Windows Defender
  • TOR Switch のアクセスリスト、SDNのアクセスリスト、Windows Firewall による通信制御
  • SMBv1 や SSLなどの古いプロトコルの無効化

認証情報のローテーション

攻撃を受ける場所を減らしたとしても、正規の入り口からの侵入を防ぐことはできません。正規の入り口で利用する認証情報をいかに強固にするか。Azure Stack Hub のアプローチが認証情報の自動ローテーションです。Azure Stack Hub は、内部で利用しているアカウントやキーのほとんどを自動でローテーションします。

  • Automated secrets rotation
    • Certificates
    • Internal accounts
    • gMSA accounts
    • Storage account keys

ただし、管理者が利用する Azure Active Directory のアカウントと PEP のアカウントは自動ローテーションの対象外です。これらのアカウントを守ることは管理者の仕事です。

暗号化

Azure Stack Hub 上のデータは BitLocker によって暗号化されます。コンポーネント間の通信は TLS 1.2によって暗号化されます。基本にして大事。

まとめ

本日のエントリでは、Azure Stack Hub のセキュリティ機能についてまとめました。Windows Server の機能を活用して、高セキュリティな基盤を実現しているのがわかります。自分たちで考えてセキュリティ対策を実装するのと、Microsoft が考えたセキュリティ対策が実装された Azure Stack Hub を使うの、どちらが安全でしょうか。私は Azure Stack Hub を使うほうが安全だと思います。難しいことは専門家に任せて、ソリューションをお金で買いましょう。