Microsoft Learn の Microsoft Azure Well-Architected Framework - セキュリティ - Training | Microsoft Learn を読んだ内容をまとめます
すこし自分の解釈も入れていきます

多層防御

セキュリティの考慮ができていない企業でセキュリティの強化をするシナリオ
多層防御 - Training | Microsoft Learn

ゼロトラスト

「信頼は前提にせずに、常に検証しましょうね」というコンセプト

なぜ必要？

従来はファイアーウォールの内側は信頼できるという境界型ネットワークが主流だった
しかし、スマホの普及などインターネットの活用が進み、社内にプライベート端末を持ち込むことも当たり前になった
(使うかどうかはさておき、鞄には入ってる)
→社内ネットワークに繋げられる端末がすべて管理下にあるわけじゃない
→信頼できない

壁がないので、一度侵入を許すとどんどん侵入範囲を拡大させてしまう

多層防御

社内と社外の境界だけでなく、いくつかの層を用意する
仮に1つの層が破られても、別の層で拡大を防ぐことができる

守られているかどうかは以下の観点を気にする

• 機密性：データが必要最小限の人だけに開示されている
• 整合性：保存時、転送時に勝手にデータが書き換えらえない
• 可用性：しかるべき人が問題なく使える

セキュリティ層

多層防御でセキュリティを向上させる場合に、どんな層があるか

それぞれの層で、どんな観点を考慮できるか

それぞれの層の詳細

データ

保護対象 (狙われるもの)

• データベースに保存しているデータ
• 仮想マシンのディスクに保存されているデータ
• SaaS アプリ (SharePoint Online とか？) に保存されているデータ
• クラウド ストレージ (OneDrive とか？) に保存されているデータ

アプリケーション

目指すべき目標

• 脆弱性がない
• シークレットはセキュリティで保護されたところに保存
• 開発に関する設計要件からセキュリティを意識

話し合わなくても、セキュリティは当たり前のものとする文化が大事

コンピューティング

攻撃を受けにくくする

• 仮想マシンへのアクセスを保護
• パッチ適用して最新の状態に保つ

ネットワーク

ネットワーク接続を必要なものだけに制限する

• リソース間の通信を制限
• 既定値を拒否にする
• パブリックなインターネットからの受信を限定的にする
• パブリックなインターネットへの送信を制限する
• オンプレへの接続を保護する

境界

攻撃から守る

• DDoS 保護を実装する
• 境界ファイアウォールにより、ネットワークからの悪意のある攻撃を識別・警告する

ID とアクセス

ID を保護し、必要なアクセス権だけに限定

• インフラへのアクセスを制限 (変更できる人を減らす)
• SSO と MFA を実装
• 変更を監査

物理的なセキュリティ

タイトル通り。物理層へのアクセスを制限する

共同責任、継続的な改善

クラウドはプロバイダーとユーザーの両方がセキュリティを意識しないとダメ

• 「物理的なセキュリティ」はクラウドプロバイダーが対応する所
• 「アプリケーション」はユーザーが対応する所
  状況は変わる (脆弱性の発見。関係者の変更。利用者の変更。サービスの変更などなど) ので継続して改善を行う

ID 管理

医療機関が題材

• お医者さんは社内ネットワークで患者データを利用
• 介護士は社外ネットワークで患者データを使いたい
• 昨今の状況を踏まえて、パスワードポリシーを強化している
  • パスワード変更を頻繁に促す
  • 長く複雑なパスワードの要求
• またサービスごとに異なる資格情報の利用
• 結果としてパスワードを よろしくない方法で管理してしまっている

ID 管理 - Training | Microsoft Learn

なぜセキュリティ層に ID が必要なのか

かつては ID は社内ネットワークでの利用に限定され、設計されていた
今はこの前提が覆っている
たくさんのデバイスで、色んなサービスを利用する。それを実現できる ID プロトコルの開発が行われている。
ID を保護していくためには SSO (シングル サインオン) と MFA (多要素認証) / 条件付きアクセスを利用することが大事

シングル サインオン

管理する ID が多くなること自体がリスク
ユーザー目線
→ ID が増える
→ パスワードも増える

管理者目線
→ 管理する ID が増える (パスワードを忘れた人のリセット対応とか)
→ 管理が漏れる ID が発生する可能性

SSO を使うと ID が統一されるのでリスクが軽減
さらに ME-ID (Microsoft Entra ID) でオンプレミスと同期をしておくと、従来の ID で SSO が実現できる
※SSO のために新しい ID を使わなくてよい

多要素認証と条件付きアクセス

セキュリティを高めるために追加の認証を求めるケースはある
そもそも認証で使われる要素は以下の3つがある

• 知っているもの：パスワード、秘密の質問 (盗み見られる可能性がある)
• 持っているもの：SMS やワンタイムパスワード発行デバイス (盗まれる可能性)
• 生体情報：指紋、顔、静脈 (指紋なら複製される？顔も 3D スキャンされる？)

それぞれの要素だけであれば悪意のある攻撃されるかもしれないが、複数組み合わせることでセキュリティが高くなる

多要素認証だけじゃなく、別の保護層として「不審なアクセス元を検知する」とか「保護されていないデバイスからのアクセスを防ぐ」なども重要
それを実現するのが 条件付きアクセス。

インフラストラクチャの保護

運用環境に対してフル権限があるユーザーが間違って環境を削除してしまった
アプリのソースコードは残っていて、バックアップが生きていたので復帰はまだ簡単だった
再発しないために、どうやって保護すればよいのかを考える

インフラストラクチャの保護 - Training | Microsoft Learn

インフラストラクチャの重要ポイント

ユーザーやプロセス (自動化処理とか？) に作業ができる 最小限のアクセス許可 を与えることが大事
不要なアクセス許可を与えることで、データの損失・漏洩、サービスの利用停止を招いてしまう

色んなユーザー、プロセスが存在しており適切な権限付与が破綻してしまうかも
場合によってはワンパターンな対応になってしまうことも
これをどうするか考える

RBAC (ロールベースのアクセス制御)

アクセス許可の集合であるロールを使う考え方
セキュリティ プリンシパル (ユーザー、グループ、プロセスなど) に対してロールを付与する

ロールと管理グループ

読み取り専用や共同作成者というロールを Azure では利用する (ロールはいっぱいある)
Azure Resource Manager では以下のような親子関係がある
上位の階層で割り当てられたロールは下位の階層に継承される

graph TD
    A[管理グループ] --> B[サブスクリプション1]
    A --> C[サブスクリプション2]
    B -->|含む| D[リソースグループ1]
    B -->|含む| E[リソースグループ2]
    C -->|含む| F[リソースグループ3]
    D -->|含む| G[仮想マシン1]
    D -->|含む| H[仮想ネットワーク1]
    E -->|含む| I[ストレージアカウント1]
    E -->|含む| J[SQL データベース1]
    F -->|含む| K[Web アプリ1]
    F -->|含む| L[App Service プラン1]

この特徴を利用して、監査担当には管理グループレベルで読み取り専用の権限を与えたりする

Privileged Identity Management (PIM/特権 ID 管理)

Microsoft Entra のサービスである PIM を使うと JIT (ジャスト インタイム) での権限付与を実現することができる
また一時的に権限が付与されたユーザーの履歴を監視することができる
結果、アクセス権の過剰・無駄・乱用などのリスクを軽減できる

サービスの ID

ユーザー、グループ以外にサービスに ID を付与すると便利なケースがある
資格情報を構成ファイルに含むことは危険な行為であり、これを防ぐためにサービスに ID を付与する

サービス プリンシパル

ここで ID とはユーザー (人) をイメージすることが多いが、アプリケーションやサーバーなども対象に含めて 認証できるもの と考えます
一方でプリンシパルという言葉も似たような文脈で出てきますが、ID よりも少し守備範囲の狭い言葉で 特定のロールや要求で機能する ID です
それを踏まえるとサービス プリンシパルは「サービスまたはアプリケーションで使われる ID」と取れます

重大な処理をスクリプトを作成し、それを実行するサービス プリンシパルを用意することで 人為的なミスを防ぐことができます

マネージド ID

サービスプリンシパルは便利ですが、作成や管理が面倒になりサービスプリンシパルの利用が困難なる可能性があります
Azure のサービスに提供されているマネージド ID はこの問題を解決する可能性があります
そのためマネージド IDが利用できるサービスではこれを利用しない手はありません

暗号化

仮に何か侵害があった場合、暗号化は最後の砦になります
そのためどんな暗号化手法が取れるのかを知っておくのは非常に重要になります

暗号化 - Training | Microsoft Learn

暗号化はデータを読み取れない、利用できないようにすることです
利用するためには複合化の手順が必要になります

暗号化には大きく分けて対称暗号化と非対称暗号化があります

保存時の暗号化

利用場面の観点では保存時と転送中に分けることができます
保存時はサーバーのディスクやデータベースのデータなどです

これを有効化することで HW が悪意のある攻撃者の手に渡ってもアクセスすることを防ぎます

転送中の暗号化

インターネット経由や社内ネットワーク経由など、別の場所から別の場所へデータが移動するときを転送中とします
このときデータを暗号化するか、セキュリティで保護された経路を通す必要があります

暗号化のための分類

データには様々な種類があり暗号化をする必要があるものと、そうではないものがあります
この分類を正しくすることが重要になります

Azure における暗号化

暗号化の方式、暗号化のタイミング (保存、転送)、暗号化対象の分類を整理できたので Azure のサービスでどのように利用できるかを考えます

ストレージの暗号化

Azure のストレージは保存時に 256 ビットの Advanced Encryption Standard (AES) を使用して自動的に暗号化しており、データ取得時に複合されています
この暗号化キーに独自のキーを利用するオプションもあります

これにより万が一、Azure のデータセンターで物理的に HW が盗難にあっても攻撃者によるデータの読み取りを防ぎます

仮想マシンの暗号化

HW レベルでの暗号化は ↑ で書いた通り
しかし VHD がダウンロードされると利用される可能性があります (データの取得時には AES は複合化される)
そのため Azure Disk Encryption を使って VHD を暗号化します
この時の暗号化キーは Azure Key Vault に保存して利用します

データベースの暗号化

Transparent Data Encryption を使うと対称キーを使用してデータベースのストレージを暗号化できます
TDE は既定で有効化されています

クライアント アプリケーションで機密情報を暗号化する Always Encrypted は機密データの保護に利用されます
これにより保存時だけじゃなく転送時の暗号化も利用できます

シークレットの保護

キーを使って、暗号化・復号化が行われます
ということはこのキーをどう保護するかが非常に重要になります
また、キー以外にもパスワード、接続文字列なども安全に保存する必要があります

そこで使うのが Azure Key Vault です
Key Vault のシークレットにアクセスできるのは RBAC を使って指定することができます

バックアップの暗号化

バックアップデータも暗号化する必要がある
Azure Backup を使うと暗号化してから Azure に保存される

ネットワーク

ネットワークにおけるセキュリティの目的は通信の保護で、サービス・システム全体のネットワーク層での露出を制限する
以下の観点に気を付ける

• アプリケーションとパブリックなインターネット間
  • 外部からの攻撃を軽減
• アプリケーション間
  • 侵害された時の被害を軽減
• ユーザーとアプリケーション間
  • セキュアにユーザーへ提供

ネットワークのセキュリティ - Training | Microsoft Learn

ネットワークにおける階層型

セキュリティ全体でも階層型の多層防御をすべき
ネットワークに焦点を当てた場合でも階層型の多層防御を採択することは重要になる

インターネットからの保護

インターネットからの通信について必要な受信・送信だけを許す
Application Gateway、Azure Firewall、DDos 保護、NSG が使える

仮想ネットワーク

リソース間通信を必要なものに限定することが大事
VM 間の制限では NSG がその役割を担う

PaaS の利用を特定の仮想ネットワークに制限をするにはいくつか方法がある
そのうちの1つが サービスエンドポイント
PaaS サービスへのアクセスを制限しつつ、仮想ネットワークからのルーティングが最適化される

Learn には書かれていないが、プライベートエンドポイントを使う方法もある

オンプレとの連携

オンプレミスのネットワークと連携する必要性は出てくる
この時にいかにしてセキュリティを高めるかが重要
VPN と ExpressRoute の 2 択がある

アプリケーションの保護

アプリケーションを保護するときには以下の領域をケアする

• アプリケーションの設計
• データ
• ID
• エンドポイント

開発ライフサイクル

開発時からセキュリティを組み込むことが大事
Microsoft セキュリティ開発ライフサイクル (SDL) プロセスを使うことがお勧め
ツールを使うことも大事な一方、文化を形成していくことも重要

運用時の評価

アプリケーションが稼働したあとはセキュリティの評価を継続することが大事
脆弱性スキャンを自動化したり、テストを自動化することで運用コストを下げて継続するハードルを下げる
Defender for Cloud を使って脆弱性チェックを行うことができる

ID の確認

アプリケーションにアクセスできる人を制限することで攻撃対象領域を大幅に軽減することができる

データの保護

アプリケーションを攻撃した結果、狙われるのはデータになることが多い
転送は TLS を有効化にする、保存時に暗号化するなどを意識する

また、暗号化キーや接続文字列などのシークレットをアプリの構成ファイルに格納しないようにする
代わりに Key Vault などの安全な場所に格納し、キー自体も定期的にローテーションするようにする

まとめ

今回は W-AF のセキュリティについて整理してみました
多層防御が考え方の根本にあって、ネットワーク、ID、開発など様々な分野でどう実現していくかが大事になっています