Azure検証利用における基本的なセキュリティ対策

本記事について

本記事ではAzureを利用する際に最低限考慮しておきたいセキュリティのポイントについてまとめています。
運用ワークロードの実行環境ではなく、あくまで検証利用するAzure環境を想定していますのでその点ご容赦ください。

これからAzureを触りたいけれど誤った設定でアカウントを危険に晒してしまわないか不安、VMが踏み台にされないか不安、といった不安を解消するための初めの一歩としてお読みいただければ幸いです。
各項目に関連するMicrosoftのドキュメントのリンクを掲載していますので、詳細な実装手順などはそちらも参考にしてみてください。

セキュリティに関する考慮は多岐にわたり、Azureにおいても多数のセキュリティに関するサービスが提供されています。
本記事ではすべてを網羅するものではありませんし、運用環境の構成に応じたベストプラクティスを説明するものでもありません。本記事の内容をスタートラインとして追加の考慮も検討していただければと思います。

また、セキュリティのベストプラクティスを考慮する上ではCIS Benchmarksも非常に参考になります。
AzureやAWSに対応して資料が提供されていますのでこちらも参考にしましょう。
CIS Benchmarks

ちなみに本記事を書こうと思ったモチベーションは以下の2点です。

• Azureを利用している社内の利用者からセキュリティ観点で設計のサポートを求められることがあるが、話を聞いてみると高度なセキュリティ対策を求めているのではなく基本的な対策が知りたいケースが一定数ある
• パブリッククラウドの普及でインフラエンジニア以外がクラウドインフラを管理することも増えてきており、基本的なクラウドインフラのネットワークセキュリティに関する情報の需要があるように感じる

Azureのセキュリティ対策

セキュリティ対策の観点

利用ユーザーを大別すると、一般的に、検証環境のアカウントや環境全体のガバナンスを管理する"管理者"と単純にVMなどを構築して利用する"利用者"に分かれていることが多いかと思います。
本記事ではこの2つの観点でセキュリティ対策を記載します。

管理者向けのセキュリティ

管理者においては、Entra IDの管理とサブスクリプションの管理を対象にセキュリティ対策を記載します。
また、検証環境で問題が発生した際の対応、調査のためのログ管理、監視についても少しだけ触れておきます。

1. Entra IDのセキュリティ
   Azureを利用する際には必ずMicrosoft Entra ID (旧Azure AD)が必要になります。
   Microsoft Entra IDはID管理のサービスで、Azure利用者はEntra IDに作成したユーザーアカウントを利用してAzureサービスを利用することになります。

   • セキュリティの既定値群 (security default)を有効化しよう！
     Entra IDでは条件付きアクセスやIdentity ProtectionといったIDベースの高度なセキュリティ機能が提供されていますが、これらの機能は残念ながらデフォルトのEntra ID（Freeレベル）では利用できず、P1/P2のライセンスを必要とします。
     そんな中で、Microsoftが一定レベルのセキュリティ機能を無償で提供しているのが"セキュリティの既定値群"です。

     セキュリティの既定値群を有効化することで得られる主な効果は全ユーザーに対してAzureポータルへのログイン時にMFAを強制できる点です。
     これをおこなうだけでもEntra IDのアカウントが攻撃を受け認証を突破されるリスクを大きく軽減できますので、Entra IDをFreeで利用している環境では必ず有効化しておきましょう (最近開設したEntra IDではデフォルトで有効化されています)。

     一点MFAにおいて注意すべきポイントとしてはFreeレベルで利用できるMFAの手段はAuthenticatorアプリケーションに限定され、SMSや電話での認証は利用できない点です。
     社用スマートフォンを配布しておらず私用スマートフォンを所持していない（利用させたくない）場合などではMFAが利用できず別途ライセンスの購入が必要になりますので注意しましょう。

     参考：セキュリティの既定値群
     
     

   • ゲストアカウントの活用を考えよう！
     こちらは社内のグループウェアとしてMicrosoft 365を活用しているなどで、既に社内の情報システム部門からユーザーに対してEntra IDのアカウントが発行されている場合 (以降、社用アカウントと呼称)に活用できるシナリオになります。

     Entra IDではそのテナント内で作成したメンバーアカウントとは別に、他テナントのユーザーアカウントを招待して利用させるゲスト招待のしくみがあります。
     このしくみを利用して社用アカウントを、検証利用するEntra IDに招待することでいくつかのメリットを得ることができます。
     1. 検証環境の利用者は追加のアカウントを管理する必要がなくなる
     2. 検証環境のアカウント管理の一部を社用アカウントの管理に委任できる

     2つ目のメリットはどういうことかというと、まずテナント間の信頼設定を利用することで検証環境で利用するアカウントに対して、社用アカウントで設定されている条件付きアクセスや準拠デバイスのチェックを適用してセキュリティレベルを向上させることができることがあります。
     加えて、利用者の退職時などに検証環境でアカウントの削除を忘れてしまっても情シス部門が社用アカウントを無効化することで検証環境へのアクセス権も間接的に失わせることができる点です。

   ゲストアカウントの活用によるEntra IDライセンスのコストメリットについて記載しておりましたが、社内検証利用においては対象外となるため、ライセンス違反を誘発してしまう記載となっており削除いたしました。
   当方の確認不足につき問題のある記載を掲載してしまいましたことお詫びいたします。

   • Enttra IDの権限 (Entraロール)管理のベストプラクティスを参考にしよう！
     ロールの説明をするとそれだけで1つの記事になってしまうためロールの詳細はMicrosoftのドキュメントや他の方の解説記事を参照いただくとして、ここではMicrosoftのドキュメントで説明されているベストプラクティスを紹介しておきます。
     一点補足しますとベストプラクティスの多くの機能は残念ながらP1/P2ライセンスを必要とします。

     Microsoft Entraロールのベストプラクティス
     
     

   • サインインログ / 監査ログ
     Entra IDではユーザーやサービスプリンシパル (アプリケーション)のサインインログやテナントの設定変更操作といった監査ログをデフォルトで記録してくれています。
     本ログはFreeレベルにおいては7日分のみAzureポータル等から閲覧することができます。
     長期間のログ保存やログデータのストレージサービスへのエクスポートにはP1/P2が必要になります。

     Microsoft Entraのデータ保持
     Microsoft EntraログをAzure Monitorログと統合する
     
     

2. Azureサブスクリプションのセキュリティ

   • サブスクリプションの権限 (Azureロール)管理のベストプラクティスを参考にしよう！
     こちらもロールの話ですが、こちらはAzureのリソースにおける権限管理です。
     RBACと呼ばれることもあるAzureロールですが、Azureサブスクリプション内でリソース作成・削除、リソースに対する操作を制御します。Entraロールと混同しがちのため注意しましょう。

     こちらもMicrosoftのベストプラクティスがありますので紹介します。
     こちらはPriviledge Identity Management (PIM)利用を除いてEntraがFreeレベルであっても従うことができる内容になっていますので積極的に参考にしていきましょう。

     Azure RBACのベストプラクティス
     
     

   • アクティビティログ
     Azureサブスクリプションにおける操作履歴、イベント履歴にあたるアクティビティログはデフォルトで90日間保存され、Azure Monitorや各リソースのアクティビティログ画面にて閲覧できます。
     VMがいつ停止されたのか？NSGのルールがいつ変更されたのか？を追うことができますので活用していきましょう。
     なお、こちらはサインインログ/監査ログと異なり、Entra IDがFreeレベルであってもストレージサービスにエクスポートして長期保存可能です。Log Analyticsワークスペース等にエクスポートしておくことをおススメします。

     Azure Monitorアクティビティログ

利用者向けのセキュリティ

利用者においては、実際に構築する仮想ネットワークやVM、PaaS（ストレージ、DB、App Service等）のネットワークセキュリティについてご紹介します。

• IaaS (VM)のネットワークセキュリティ
  VMにおけるネットワークセキュリティで重要になるのはまずNetwok Security Group (NSG)を正しく活用することです。
  RDPやSSHによる管理アクセス、HTTPS等でのWebアクセス、いずれにおいても最低限のネットワークアクセスを許可し、不要なアクセスは拒否しておくためにはまずNSGを活用してみましょう。

  NSGはサブネットもしくはNICのいずれか、もしくは両方に対して適用可能な無償のファイアウォール機能です。送受信について制御可能ですが、受信についてはデフォルトでは仮想ネットワーク内からのアクセスとAzure Load Balancerからのアクセスのみが許可され、その他のアクセスは拒否されています。
  そのため、VMへの管理アクセスをおこなうためには必要に応じてアクセスを許可するルールを追加していくことになりますが、このときに送信元のIPアドレスについて厳密に制限しておくことが重要になります。

  よくある設定例としては自社におけるグローバルIPアドレスや自社で利用しているクラウドプロキシサービス等のグローバルIPアドレスを送信元として設定しておくことで、社外からのアクセスを拒否するといったものが挙げられます。

  NSGを使う上で注意すべき点をいくつか列挙しておきます。

  • 原則としてサブネットかNICいずれか片方のみに設定しましょう
  • FQDNでの制御はできません (アクセス先をFQDNで絞る場合などはAzure Firewallの活用を検討しましょう)
  • Virtual NetworkサービスタグにはVPNやExpress Routeで接続しているプライベートIPアドレス空間も含まれます
  • 通信記録を保存したい場合はNSGフローログを活用しましょう
  • NSGフローログには記録されない通信も存在するので注意しましょう (ICMPやPaaS宛ての通信)

  ネットワークセキュリティグループ
  ネットワークセキュリティグループのフローのログ記録

  一方で、テレワーク等により信頼できるグローバルIPアドレスが指定できない場合には少しハードルが上がります。都度その時の接続元グローバルIPアドレスを許可設定に追加することも考えられますが、設定の手間もかかりますし、第三者とIPアドレスを共有している環境であればセキュリティ上の懸念も発生します。
  その場合は、マネージドの踏み台サービスであるAzure Bastionを利用するか、ポイント対サイトVPNによる仮想ネットワークへのSSL VPNのサービス利用を検討しましょう。Bastion利用時は操作性に難が出たり、VPN利用時は証明書の管理等、管理者の手間が発生したり、また、いずれにしても追加のネットワークリソースの費用もかかりますが、ここはコストを惜しまずに安全なリモートアクセスのしくみを作ることを推奨します。

  Azure Bastionとは
  ポイント対サイトVPNについて
  
  

• PaaSのネットワークセキュリティ
  PaaSにおいても基本的な考え方はIaaSと同様にアクセスを最小限に制限することが重要になりますが、PaaSにおけるネットワークセキュリティは利用するサービスによって変わってきます。
  今回の記事では詳細な説明は省略しますが、多くのサービスに共通する考え方について紹介します。また、参考にApp Serviceにおける該当サービスのURLを載せておきます。

  • PaaSは基本的にデフォルトでインターネットに公開される (ことが多い)ものである
  • PaaSへのアクセス制御にはPaaSのファイアウォール機能を活用しましょう
    Azure App Serviceのアクセス制限を設定する
  • さらにアクセスをプライベート通信のみに制限したい場合はプライベートリンクを活用しましょう
    App Serviceアプリにプライベートエンドポイントを使用する
  • PaaSから仮想ネットワークへのアウトバウンドの通信はVNet統合を活用しましょう
    アプリをAzure仮想ネットワークと統合する
    
    

• VM等のアカウント管理
  最後に当たり前のことではあるのですがアカウントのデフォルトID名やパスワード設定についても注意しておきましょう。
  セキュリティ事故の話を聞くと、ネットワークセキュリティの設定不備やネットワーク機器の脆弱性を放置してしまったことがトリガーになったものの、最終的にはシステムでデフォルトID名を設定していたり、パスワードが安易に推測可能な文字列だったために、不正アクセスを受けてしまったというケースがあります。
  VMのユーザー名のデフォルトである"azureuser"やデータベースのデフォルトユーザー名(ex. postgres)、パスワードについては、推測されづらい名称に変更しておきましょう。

最後に

ざっと思いつく基本的な事項のみを説明してきましたが、AzureにはDefender for Cloudを中心としたセキュリティサービスやAdviser等の評価機能もあります。
また、ログ管理や監視、VMの更新プログラムの適用等もセキュリティを考える上では検討必須です。さらに、今回の内容ではWebアプリのインターネット公開時のセキュリティには言及できておりませんが、認証・認可をどうおこなうか、Web Application Firewallを設置してWebアプリへの攻撃をいかに防ぐかといった考慮も必要になってきます。

加えて、セキュリティサービスはもちろんのこと、ベストプラクティス自体も時間とともに変化していくため、最新のトレンドを追っておくことも重要です。IPAの情報などを活用してセキュリティトレンドをおさえておくことも必要でしょう。
上記の基本的な内容をベースに、利用環境に応じたセキュリティ設計をおこなって安全にAzureを利用していきましょう！