Azure環境作ったら最初にやるべきこと（2025年版）
はじめに
Azure環境作ったら最初にやるべきこと（2021年版）という記事を4年ほど前に書きました。
非常にアクセスも多く、いまだによく読んでいただいている記事なのですが、さすがに4年も経つとちょっと古いよなぁと言うところも目立つようになってきました。
もともと、AWSでは「初めにやるべきこと」というのが色々な方が書かれていて、非常に有用な知見が共有されていると思います。Azure界隈ではそこらへんの情報共有が少なく、一方でここ1～2年は「Azure OpenAI」の台頭もあって、「Azureをちょっとだけ使いだしたんですけど～」という方が増えている印象です。
…となると、より一層「これだけはやろうね」というスタートガイドのようなものが重要になってくるのではないでしょうか。ということで改めて書き直してみたいと思います。
「Azure環境作ったら最初にやるべきこと」の定義
この場では「どんなサービス／リソースを使うかに関わらず、誰もが全環境でやるべき最初のステップ」という主旨ととらえていただければと思います。
Azure環境を運用していくうえで、「SQL Databaseのベストプラクティスは何？」とか「WebAppsだったらこうやって使うよね」とか細かい設定を挙げると色々あるのですが、そのレイヤーは対象外。
なので、基本的には「Azureを使う全ての人」にとって意味のある記事になってるはずです。
中身について
「アレが足りない」「コレはやらなくていいんじゃないか」に気付かれる方も多いかと思います。ただ、叩き台になればよいと思って公開してますので、これに触発されて何かしらコメントいただけるといいなと思います。
本文
サインアップ
契約種別を決める
今回の環境は、「MOSP/直接MCA」を前提に記載していきます。
企業ユースの方などは、きっと「CSP」や「EA」の環境を持っているかと思いますが、CSPやEAだと特有の事情で使えない機能や設定があるかもしれないので、そこら辺は適宜読み替えてください。
そもそもMCAとかCSPって何ぞやと言うことであれば、以前別の記事で整理しましたのでこちらもご確認ください。超ざっくり言えば、直接MCAは個人向け／小規模向けなAzure利用モデルです。こういう記事を読まれている方は「MOSP/直接MCA」を使うことがほとんどだと思います。
利用開始
MicrosoftのウェブサイトからAzureの利用開始手続きを進めていくと、おそらく「無料試用版」になっています。時期（12か月）が来たら、あるいは無料試用版の制限を超える利用を見込む場合、まずサブスクリプションをアップグレードして「従量課金」にします。
※3年ほど？前から、Azureプラン化／直接MCA契約への変更が行われていて、MOSP契約は無くなるはずと思っているのですが、いまだに切り替えが終わりません。新規作成時もMOSPで作られる…というようなドキュメントがちらほらありますね。利用者的にはあまり気にしなくてよさそうですが、どういう方針なのか知りたいものです。
なお、一度作ったサブスクリプションを別の契約配下に移すことは可能な組み合わせもあります。ですが、ドキュメント上でOKとなっているのに変な制約にハマったことが何度かありますので、実施される際は超慎重にお試し下さい。
ですので、（特に企業ユースの場合は）どういう契約で利用開始するかは慎重に決めましょう。
アカウント管理者のMFA
MSアカウントを使ってAzureアカウントを開設したことを前提に…（Githubアカウントでも同じだと思いますが、やったことが無いので割愛。）
Microsoftアカウントポータル＞セキュリティからMFA（2要素認証）を設定します。
Windows Helloやubikeyのような生体認証と組み合わせるのも便利ですが、本記事が対象にするような「初めて使いだします」な環境においては、お金をかけずにアプリでコード払い出し、というのがバランスがいいと思います。
MS製なので、Microsoft Authenticatorが基本的にはオススメですが、既に使っている環境とあえて分けるほどではないので、管理しやすいものを使いましょう。
私はスマホアプリでMicrosoft Authenticatorを入れており、ログイン時に通知＋通知に対して「ログイン画面側で通知された数字を入力」で認証が通るようにしています。アプリの起動自体を指紋などスマホ側で保護できるので、便利と安全のバランスが良いと思います。
アプリやSMSに通知されるコードを使ってMFAを行ったり、電話で認証するパターンもよくあると思いますが、面倒くさい手順にするとついつい外してしまうので注意が必要です。また、セキュリティ界隈では、メールやSMSでコードが通知される方式は一段弱いとされていますので注意です。
※2025年現在、サインアップ時にMFAを設定するようになっている気もしますが、ちょっと正確なフローが分からなかったので情報提供いただければ訂正・修正します。
また、ここまでMFAと書いてきていますが、正確に言うとここで設定しているのは「2段階認証」ですね。2要素認証と2段階認証は意味が違う（セキュリティ強度も異なる）のですが、気になる方は用語調べてみてください。
アカウント管理者の封印
アカウント管理者（サインアップしたアカウント）は、課金周りなど何でもいじれるスーパーユーザーです。また、作成したサブスクリプションの「所有者」となり、全ての操作を実施可能ですです。
（※元々、サブスクリプション作成時に「サービス管理者」という所有者相当の権限が付与されていましたが、2024年8月31日で「サービス管理者」は廃止されており、「所有者」の権限が付与されるようになっています）。
AWSでいうところのルートアカウント相当であるため、通常の運用では使わないべきです。アカウント管理者を使う必要があるときのみ、使うにしましょう。
（参考）
サポートプランの確認
Azureポータルに戻り、ヘルプとサポート＞サポートプラン、から適切なサポートプランに変更します。
Basic＜Developer＜Standard＜Professional Directと、
問い合わせ可能な内容や、応答時間などのサービスレベル、そして価格がアップグレードされていきます。その環境に必要なサポートレベルで契約しましょう。
企業で使われるような方は、ユニファイドサポート（昔ながらの言い方で言う、プレミアサポート）もご検討下さい。
※2025年現在、サインアップ時に選択できるようになってますね。
ログ保管
何かあったときに、状況を追うために必要になります。何はともあれまずこれを作成します。
予め保存先を作成する
リソースグループ、およびストレージアカウントを作成します。
リソースグループについては、基本となるリージョンを選んでおけば特に迷うことは無いと思います。なお、リソースグループのリージョンと、リソースグループの中に入れるリソースのリージョンは一致している必要ありません。直感的ではないですが、あくまでそういうものと覚えましょう。
BCP（DR）要件、統制要件などなければ遠いリージョンに作る意味もないので、普段の接続元に近いところから選択すればよいと思います。
ストレージアカウントに関しては、必要なレベルのレプリケーションを設定しましょう。個人で使うレベルではLRSで十分かと思いますが、要件に応じてGRSなど検討しておきましょう。
また、ストレージアカウントの設定において不要な要素は無効にしておきましょう。
・「BLOBパブリックアクセスを許可する」を無効にする
・許可するアクセス元は「すべてのネットワーク」じゃなくて「選択されたネットワーク」にし、例外「信頼されたMicrosoftサービスによるこのストレージアカウントに対するアクセスを許可します」を設定する。
あたりが基本だと思います。
これでMS外からの攻撃はかなりやりづらくなりますが、Azure内のログ保存は可能です。なお、自分がデータを見るための適切な穴あけは、別途ご検討ください。「今つないでるIPアドレスからは、接続許可」というのがAzure Portal上で簡単に設定できます。IPアドレスが固定されている環境からなら便利なのですが、個人の自宅からだと実現できるプロバイダーは少し限られますね…。
なお、「信頼されたMicrosoftサービス」を許可するとどれくらいアクセスされるの？というのは、別記事でまとめたものがありますのでこちらご参照ください。（自分の管理範囲からしかアクセスできないので、基本的に安心して大丈夫です。）
Entra IDログ（SigninLog）の保管
まずはサインインログの保管設定を行います。何かあったときに、誰がやったのかを明らかにするためです。「Entra ID」＞「監視」＞「診断設定」から実施します。
画像は最低限の情報で、ユーザープリンシパルのサインイン情報（SigninLogs）と、グループやADロールの変更ログ（AuditLogs）を指定していますが、ManagedIDやServicePrincipalに関しても収集したほうがもちろん良く、基本的には全てを指定しましょう。保存先には先ほど作成したストレージアカウントを指定します。
※出力先として、LogAnalyticsを指定し、検索しやすくしたりSentinelで分析する方もいらっしゃると思いますが、今回は最低ラインと言うことで保存・保管までを説明しています。
※スクショは少し古く「保有期間」を指定するUIになっています。2025年現在は、ログローテーションはこの画面では指定せず、ストレージアカウント側の機能で実施することになっています。
ActivityLogの保管
Azureサブスクリプションにて、リソースレイヤの操作のログを保管します。これも、誰が何をやったか後から追えるようにするためですね。
「サブスクリプション」＞「アクティビティログ」＞「診断設定」から実施します。
データの量に応じて料金が多少かかりますが、ログの類はいつ何のために使うことになるか分からないので、こちらも選択できる種別全て指定しておくのが良いと思います。保存先は先ほど作成したストレージアカウントを指定しましょう。
なお、Entra ID側のログもそうですが、カテゴリは増えることもあるので、情報収集や画面チェックが欠かせません。
ストレージアカウントの保護
AzureADログ、ActivityLog保存先に指定したことで、Blobコンテナが自動作成されています。このBlobコンテナに対して、コンテナレベルでの保護を行います。せっかく操作ログの類を取っといても、ウッカリあるいは悪意で消されてしまっては意味がありませんので、しっかり保護しましょう。
対象ストレージアカウント＞コンテナー＞個別のコンテナの設定＞アクセスポリシー、を選択し「不変Blobストレージ」を設定します。
この手のログに関しては、保存期間を指定するのが一般的でこちらは必要性に応じて設定すればよいですが、「その他の保護された追加を許可する」をチェックすることを忘れてはいけません。
（「その他の～」をつけ忘れると、ログ書き込みに失敗するので注意が必要です。）
診断設定で出力されるサインインログやアクティビティログは、1時間ごとに新しいログファイルを作成→イベントが発生すると追記→追記という動作をする仕様上、ログファイルへの追記を許可する必要があります。これが許可されていないと、空のファイルが毎時作成されるだけになってしまい…ファイルが作成されている分たちが悪く、いざ見ようと思ったら空ファイルだったという悲劇が起きかねません。
以上に気を付けておけば、安全にログ保管ができます。
ID管理／権限管理
MFA設定
アカウント管理者はMFAを設定済み、封印することになっていました。今度は通常使うアカウントを保護する方法を考えます。
MFAを設定すること自体はベストプラクティス上も常識になっています。何処まで守るかは、その環境に置かれるデータの重要性次第、その環境で行う業務の重要性次第です。とはいえ少なくとも更新権限を持つアカウントには実施し、制約が無ければ参照権限だけのアカウントでも保護したほうが良いと思います。
保護の方法は、2種類あります。（本当はもう1種類ありますが、むかーしサポートに問い合わせた際に「今後は条件付きアクセスに寄せるので、今から使うのは推奨しない」と回答もらったので、割愛します。と、2021年版の記事でも書きましたが、2025年現在まだ使えますね。なんなんだろう…）
セキュリティデフォルト
現在は、Entra IDテナントを作成すると、最初から有効になっていますので、特に意識する必要はありません。この機能が有効だと、「全てのアカウントに対しMFA登録を必須とする」動きになります。
無償で使えるので、誰もが有効にしておくべき設定であり、これを解除することのメリットは無いと思います。
条件付きアクセス
条件付きアクセスは、認証認可において（MFAに限らず）高度な制御を行いたい場合に使用します。
例えば、接続元のIPアドレス制限や除外設定（ユーザー単位、アプリケーション単位で指定）を合わせて実施したい場合に使うことになります。MFAだけではセキュリティ的な要件を満たさない場合は、条件付きアクセスを使って実現します。
よく聞くのは「基本的にMFAを求めるけど、社内からで認証された端末を使っている場合はMFAを免除」みたいな使い方でしょうか。
条件付きアクセスは、セキュリティデフォルトと排他的にな設定となるので、要件をよく見極める必要があります。また、条件付きアクセスの制御対象となるユーザーアカウントには「EntraIDのP1以上のライセンス」が必要になるので、かかるコストは最初から見込んでおきましょう。P1ライセンスを所持していないと、設定すらできません。
詳細と言うほどではありませんが、これも別記事でまとめたものがありますのでご参照ください。
ユーザー作成／グループ作成
個人別にユーザープリンシパル（＝アカウント）を作成、役割でグループを作成、権限はグループ単位で付与しましょうというのがベストプラクティスです。
個人別ユーザープリンシパル
「管理者ユーザー」のパスワードをみんなが知ってて、みんなで共用するのはもってのほかです。人狼が混じったときに、誰の犯行か分からなくなるので、当然アンチパターン。
なお、「その端末を使った記録」などの他の仕組みと組み合わせて個人を特定できるなら共有アカウントの利用もアリかもしれません。ただし、複数ログを組み合わせて調査する必要が出てくるため、（面倒くさいので）普通は推奨されません。よって、原則的には人別でユーザープリンシパルを作成しましょう。
グループでの権限付与
環境・ユーザー数の規模にもよりますが、基本的に個別のユーザープリンシパルに権限を与えていくと、管理する数が増えすぎて破綻します。また、Azureの世界でも「権限の割り当て」定義にクォータが存在することもあり、ベストプラクティス通り素直にグループを作成してグループに対して権限を与えるようにすることが推奨されます。
なお「グループに対するEntra IDロールの付与」は長らくプレビュー機能だったと思うのですが、GA済ですね。
「グループに対するAzureロールの付与」は特にプレビューといった制約はありませんので、確実にグループに対して権限を付与しましょう。
（Entra IDロールと、Azureロールの違いは後続の項目をご確認ください。）
管理者
管理者（Entra IDでいうグローバル管理者）は複数人（数名）用意することが推奨されています。ニュアンスが難しいですが、
・「1人しかいないと、PW忘れ、退職、その他トラブル時に誰も管理できなくなってしまう」
・「多すぎると、統制が取れなくてみんな好きかってに使ってしまう」
ということで、2～4名くらい…ということが推奨事項です。
個人で使う環境であれば自分だけになりますが、ちょっとした組織で使うときはご検討ください。
緊急用ユーザー
先ほどの項目で条件付きアクセスを設定していますが、これの例外となるユーザーを作成することがあります。条件付きアクセスは接続元の環境、IPアドレスや端末を指定して認証認可を行えますが、設定ミスにより「ロックアウト（誰も入れなくなる）」してしまうことがあります。
私も数回か事象を見たことがありますが、この場合はMSサポートに依頼して条件付きアクセスを解除してもらうことになります。ただ、本人確認と合わせてかなり時間がかかるんですよね。（しかもこれ、正式にやれますとはどこにも書かれてない気がします。なので「できない」と言われても文句は言えない…。）
ということで、条件付きアクセスの対象外となる「緊急用ユーザー」を作っておくことが推奨されています。
その他
また、ウッカリミスは誰だってするモノなので、できるだけ管理用のアカウントと日常使いの参照用アカウントは分けておいた方が良いです。ただし管理できないレベルで分けてしまって、パスワードを付箋でモニターに貼るようになったら本末転倒なのでほどほどに。
改めてですが、特に「アカウント管理者」は「アカウント管理者が必要な時」以外は使用しないようにしましょう。EntraIDテナントやサブスクリプションの作成レベルの作業くらいなので、小規模な環境であれば最初だけです。
ロールの設定
Azureでは、「ロールベースのアクセス制御」と言う考え方が基本にありますので、
EntraIDに対するEntraIDロールの設定と、サブスクリプション対するAzureロールの設定を行うことで権限を付与します。
EntraIDロールはグローバル管理者が最高権限、Azureロールは所有者が最高権限ですが、安易には使わず、そのユーザーに与えるべき権限をよく見極めて設定しましょう。
このあたりの概念は以下の記事でまとめています。
「最小権限の原則」を考えると、必要な権限だけに絞り切ることが推奨されますが、そこまでやってられない…！と言う場合でも、最低限、閲覧権限＜更新権限＜権限を弄れる権限、の3段階くらいは検討すべきかと思います。
カスタムロールを駆使して、本当にギリギリな権限に絞り込むのは…できるのですが、茨の道なのであまり推奨しません。超、お堅い、最初触ったらあんまり構成変更しないシステム…だったらやってもいいかもしれませんが。。
パスワードポリシーの設定
文字数や複雑さ、更新頻度などを設定することを推奨する時代がありました。（今もまだ、その文化は残ってますね…）
EntraIDにおいては、「強力なパスワード」はデフォルトで有効です。2025年現在は「MFAを有効にすること」がベストプラクティスであるため、その代替策である「パスワードを複雑にし、有効期限を決め、ローテーションをしましょう」というのは積極的に推奨されていません。どうしてもMFAを使えない場合を除き、特に意識しなくてよいと思います。
（ご参考ですが、公式ドキュメントにて上記のように語られています。）
パスワードセルフリセット
（P1ライセンスを適用している環境だったら）セルフサービスパスワードリセット（SSPR）を設定することが推奨されます。一般的に、パスワード忘れの対応は何も価値を生み出さないタスクの割に、管理者にとってとても負担になりますので、できるだけユーザーセルフでできるようにしておくこと、というのが推奨事項です。
ただし、自分ひとり／数人で使うような少ない環境であればわざわざ設定するほどではないかなと思います。
環境保護
サービス正常性／リソース正常性と通知
ヘルプとサポート＞サービス正常性から、2つの通知を有効化します。
どこまでチェックを入れるかは環境の大事さと好みによりますが、概ね全ての環境で推奨できるのは
- サービス正常性は「全て」、
- リソース正常性は「Available」が「Degraded」や「Unavailable」に変化した場合
くらいはアラートを指定し、チェックした方がよいと思います。
1.サービス正常性アラートの指定
2.リソース正常性アラートの指定
いつ止まっても大丈夫…な検証環境であればそれすらやる必要はありませんが、個人のブログ運営程度でも止まったら気づきたいものです。
Microsoft Defender for Cloud有効化
以前は、有償版の試用をするか、無償版で利用するかの選択が冒頭にあったのですが、今は何もしないと無償版で開始するようなUIに見えます。ただ、一度アクセスしないと有効化されないようなので、まずは一度Azure Portalで「Defender」を検索して、一度開くようにしましょう。
無償でも、最低限必要なチェックを開始してくれて、「セキュリティスコア」を表示してくれます。
いわゆる「基本的なCSPM」です。Microsoft クラウド セキュリティ ベンチマークに沿ってチェックが行われます。
有料プランにすると、その他の「規制コンプライアンス標準」（業界ごとのルール集のようなもの）によるCSPMや、ワークロードに対する脅威検知（CWPP）の機能が使えるようになります。また、何かを検知した時にどこまでお金をかけてどこまでやるかは検討が必要ですが、無償の範囲は活用しましょう。
Sentinel有効化
よくある「攻撃を受けている、不穏な動きには気づけるようにしたい」あるいはAWSでいう「Rootアカウントのサインインには気づけるようにしようね」を最低ラインと考えて、最低限は設定したいところです。少し古いのですが、別記事でまとめたものがあります。 ただ、Sentinelはなかなか「ここまではやろうね」「これくらいはやろうね」と言った情報が世の中にもまだあまりない気がします。
請求
サブスクリプション請求書のDL設定
請求書をアカウント管理者以外でDLできるようにする
アカウント管理者を日常的に使わなくていいようにしておくため、本設定を行います。本設定を実施しておくことで、「請求閲覧者」などの適切なAzureロールがあれば、他のユーザーアカウントでも請求情報を参照できるようになります。
サブスクリプション＞請求書＞請求書の招請の編集＞請求書のダウンロードを他のユーザーに許可する
からの、「オン」にして「保存」を忘れずに
メール受信設定
また、同じ画面の「請求書を電子メールで受信する」より、アカウント管理者が初期設定されていますが、必要に応じて追加しましょう。
ACM（Azure Cost Management）の設定
Budget/Alertの設定
「予算」から予算と通知を設定します。
超えたらマズいラインを設定しておいて、「思ったよりうっかり使ってしまった」や「乗っ取られて使われてしまった」に気付きやすい状況にしておくことが推奨されます。世の中のセキュリティ事故の例を見ると、「VMを立ち上げられてマイニングに使われてしまった」などもよくありますので、防ぐ／気づく手段を多重に持っておくことは大事です。
通知の段階として、予算に対する進捗率を入力する事も可能なので、何段階か設定しておくのが有効かと思います。
私も、サラリーマンのお小遣いを超えるくらいには…やらかしてしまったことがあります。傷は浅いうちに気付けるようにしましょう。
M365管理センターの設定
サブスクリプションの請求と、EntraID関連のライセンス等の請求は独立しています。ここでは後者に関する通知を設定します。
請求書に関しては、サブスクリプションの方と同様に、メールで受け取れるようにすることがベターです。ただ、Azureリソースと違って「ウッカリ使いすぎてしまった」ということはあまりないですよね。そこまでシビアじゃなくていいかなと言う気がします。
その他
通知言語の設定・技術部連絡先設定
EntraID＞プロパティから、「通知言語」をなじみ深いものにしておきましょう。
デフォルトがEnglishなので、日本語にしておきたいものです。
また、技術部連絡先は初期設定だとアカウント管理者のアドレスになっているはずです。これも、情報を受け取るべき人に変更しておいた方が良いでしょう。
ディレクトリ名
上記の同じ画面で、「ディレクトリ名」を変更できます。Azure Portalの右上に表示される文字列兼、ログイン先の切り替え時などに表示されます。デフォルトの「既定のディレクトリ」でも困りませんが、複数環境を管理する方は分かりやすく変えることで、操作ミスなどの事故のリスクを低減できます。
APIなどの引数では「テナントID」というUUID形式の文字列を使いますので、ディレクトリ名は人間が見て識別する用途でしか使いませんので、見てわかりやすいというのが一番大事です。
見ての通り、日本語名で指定できます。
サブスクリプション名
同様にサブスクリプション名も分かりやすいものに変更しましょう。
サブスクリプション＞概要＞サブスクリプション名のリンクから変更することが可能です。
見ての通り、日本語名で指定できます。
連絡用メールアドレスの設定
作成した管理者アカウントに対して、「連絡先メールアドレス」を設定しておきます。
※図は空のままの例です。これは良くないので、「編集」から入力しましょう。
Azureの仕様上、「管理者に通知する」となっている設定箇所があり、メールアドレスを設定しておかないと通知が来ないためです。
例えば「Azure Defender for SQLの脅威検知の通知先」などで「サブスクリプションの所有者」といった通知先設定が出てきますので、管理者アカウントに対しては連絡先メールアドレスを正しく設定しておくことが重要です。
Azure Advisorの設定
全般
サポートレベルに関係なく、チェックしてくれます。（AWSのTrusted Advisorはサポートレベルによってチェック範囲がちがいますので、考え方の違いに注意です）
様々な設定項目に対する推奨事項を提示してくれる機能なので、定期的に見るとよいと思います。
アラートの設定（プレビュー）
定期的に画面上でチェックするだけでなく、新たに推奨事項にひっかかるリソースが検出された場合に通知を貰えるように構成できます。
推奨事項のレベル「高」などは、通知を入れるとよいと思います。全部にチェックを入れると、きっとオオカミ少年になってしまい見なくなってしまうので、ほどほどが重要です。
徐々に推奨事項の低いレベルまで対応していきましょう。
おわりに
以前書いた記事からUpdateして、令和最新版にしました。プレビュー機能だからどうしようかな、みたいな扱いだったところが正式にＧＡされ、推奨できる設定になってたりしますね。
※一方で、スクリーンショットの類は更新をサボったところがあります。仮に最新化しても、Potal上の表示なんてすぐ変わってしまうので、すぐ微妙な差が出てしまいます。なので、考え方さえ変わってなければいいやとしてそのままにしています。（イイワケ）
大きく項目が増えたりはしていませんが、皆様のご参考になれば幸いです。
Discussion