Aimless

Azure Stack のセキュリティ

azurestack

はじめに

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

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

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

ビジョン

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

Internals are internal

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

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

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

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

制限付き管理者

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

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

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

API で Azure Stack を操作できない時のため用意されている、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 用に作られたものばかりです。したがって、管理者は 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 を運用管理する人を “Azure Stack Operator” と呼んでいます。”Azure Stack Administrator” ではありません。

ハードウェア周りの実装

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

  • Secure Boot
  • UEFI
  • TPM 2.0

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

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

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

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

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

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

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

暗号化

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

まとめ

本日のエントリでは、Azure Stack のセキュリティ機能についてまとめました。Windows Server の機能を活用して、高セキュリティな基盤を実現しているのがわかります。

自分たちで考えてセキュリティ対策を実装するのと、Microsoft が考えたセキュリティ対策が実装された Azure Stack を使うの、どちらが安全でしょうか。私はAzure Stack を使うほうが安全だと思います。難しいことは専門家に任せて、ソリューションをお金で買いましょう。

11 Dec 2018