Azure環境作ったら最初にやるべきこと（2021年版）
はじめに
Azure環境作ったら最初にやるべきこと（2021年版）と題して一記事書いてみたいと思います。
※補足事項
「Azure環境作ったら最初にやるべきこと」の定義
この場では「どんなサービス／リソースを使うかに関わらず、誰もが全環境でやるべき最初のステップ」という主旨ととらえていただければと思います。
Azure環境運用していくうえで、「SQL Databaseのベストプラクティスは何？」とか「Web Appsだったらこうやって使うよね」とか細かい設定を挙げると色々あるのですが、今回は対象外。
なので、基本的には「Azureを使うすべて人」にとって意味のある記事になってるはずです。
先駆者たちの情報を探す
AWSだと個人のブログもいっぱいあるし、かの有名なClassmethodさんのブログでもこういった記事がまとめられています。
初心者に優しいというか、いろんな情報が転がっていて、「AWS使い始めるか～」って時にすぐに情報が出てきます。
（いきなり人のブログを出して、しかもAzureじゃなくてAWSなの何なの？と思われたと思いますが、zennの運営はClassmethodさんだし許されるだろ…ということで気にせず進めます）
では改めて、Azureってどうやって使い始めるの？って思ってググってみると、ほとんど情報が無い（あってもあまり新しくない）ということが分かりました。ここは一発自分で書いてみるかと言うことで、一念発起してみましたというのが背景です。
今回やりたいこと
とはいえ元が無いと苦しいわけですが、パブリッククラウド観点で見たらやるべきことなんて基本的にはAzureだろうとAWSだろうと変わらないと思うので、既存のAWSに関する世の中の情報を参考に記載していきます。というか、Classmethodさんの「AWSアカウントを作ったら最初にやるべきこと ～令和元年版～」の章立て（大項目）を大いに参考にさせていただいています…
中身について
そこまで深く考えられていない項目、知識が足りないみたいなところもありますが、「あれが足りない」「これはやらなくていいんじゃないか」みたいな議論が起こる方がうれしいので、抱え込まずにまずは一度知識を吐き出したいと思います。
本論
サインアップ
契約種別を確認する
普通の個人が通常使うMOSPを前提に記載します。
CSPやEAだと特有の事情で使えない機能や設定があるかもしれないので、そこら辺は適宜読み替えていただくとして。
なお、そもそもMOSPとかCSPって何ぞやと言うことであれば「MOSP CSP 違い」あたりのワードで検索すれば情報出てきますので、今回は割愛します。
超ざっくり言えば、MOSPは個人向け／小規模向けなAzure利用モデルです。
オファーを切り替える
利用開始時は、普通は「無料試用版」になっています。
時期（12か月）が来たら、あるいは無料試用版の制限を超える利用を見込む場合は、まずサブスクリプションをアップグレードして「従量課金」にします。
必要に応じて、オファーの切り替えを行いましょう。Visual StudioやMSDNの利用者向けの、クレジット特典などを使えるので、何らかのライセンスに紐づく権利を持っているのであれば積極的に使いましょう。 手順は上のリンクに記載がありますが、私は特にライセンスを持っておらず無料試用版のママです…。
アカウント管理者のMFA
MSアカウントを使ってAzureアカウントを開設したことを前提に…（Githubアカウントでも同じだと思いますが、やったことが無いので割愛。）
Microsoftアカウントポータル＞セキュリティからMFA（2要素認証）を設定します。
MS製なので、Microsoft Authenticatorが基本的にはオススメだろうと思いますが、他社製品でも特に問題はありません。既に使っている環境とあえて分けるほどではないので、管理しやすいものを使いましょう。
私はスマホアプリでMicrosoft Authenticatorを入れており、ログイン時に通知に対して「OK」で認証が通るようにしています。アプリの起動自体を指紋などスマホ側で保護できるので、便利と安全バランスが良いと思います。
アプリやSMSに通知されるコードを使ってMFAを行ったり、電話で認証するパターンもよくあると思いますが、面倒くさい手順にするとついつい外してしまうので注意が必要です。
アカウント管理者の封印
アカウント管理者（サインアップしたアカウント）は、課金周りなど何でもいじれるスーパーユーザーです。また、作成したサブスクリプション周りの操作もできてしまいます（サービス管理者という所有者相当の権限が付与されます）。
AWSでいうところのルートアカウント相当であるため、通常の運用では使わないべきです。
（参考）
アカウント管理者を使う必要があるときのみ、使うにしましょう。
サポートプランの確認
Azureポータルに戻り、
ヘルプとサポート＞サポートプラン、から適切なサポートプランに変更します。
Basic＜Developer＜Standard＜Professional Directと、
問い合わせ可能な内容や、応答時間などのサービスレベル、そして価格がアップグレードされていきます。その環境に必要なサポートレベルで契約しましょう。
ログ保管
何かあったときに、状況を追うために必要になります。何はともあれまずこれを作成します。
予め保存先を作成する
リソースグループ、およびストレージアカウントを作成します。
リソースグループについては、基本となるリージョンを選んでおけば特に迷うことは無いと思います。なお、リソースグループのリージョンと、リソースグループの中に入れるリソースのリージョンは一致している必要ありません。直感的ではないですが、あくまでそういうものと覚えましょう。BCP（DR）要件、統制要件などなければ遠いリージョンに作る意味もないので、普段の接続元に近いところから選択すればよいと思います。
ストレージアカウントに関しては、必要なレベルのレプリケーションを設定しましょう。個人で使うレベルではLRSで十分かと思いますが、要件に応じてGRSなど検討しておきましょう。
また、ストレージアカウントの設定において不要な要素は無効にしておきましょう。
・「BLOBパブリックアクセスを許可する」を無効にする
・許可するアクセス元は「すべてのネットワーク」じゃなくて「選択されたネットワーク」にし、例外「信頼されたMicrosoftサービスによるこのストレージアカウントに対するアクセスを許可します」を設定する。
あたりが基本だと思います。
これでMS外からの攻撃はかなりやりづらくなりますが、Azure内のログ保存は可能です。なお、自分が見るための適切な穴あけは、別途ご検討ください。
AzureADログ（SigninLog）の保管
まずはサインインログの保管設定を行います。何かあったときに、誰がやったのかを明らかにするためです。
「Azure Active Directory」＞「サインイン」＞「データ設定のエクスポート」＞「診断設定」から実施します。
画像は最低限の情報で、ユーザーのサインイン情報（SigninLogs）と、グループやADロールの変更ログ（AuditLogs）を指定していますが、ManagedIDやServicePrincipalに関しても収集したほうがもちろん良く、基本的には全てを指定しましょう。保存先には先ほど作成したストレージアカウントを指定します。
ActivityLogの保管
Azureサブスクリプションにて、リソースレイヤの操作のログを保管します。これも、誰が何をやったか後から追えるようにするためですね。
「サブスクリプション」＞「アクティビティログ」＞「診断設定」から実施します。
データの量に応じて料金が多少かかりますが、ログの類はいつ何のために使うことになるか分からないので、こちらも選択できる種別全て指定しておくのが良いと思います。保存先は先ほど作成したストレージアカウントを指定しましょう。
なお、AzureAD側のログもそうですが、カテゴリは増えることもあるので、情報収集や画面チェックが欠かせません。1年くらい前までは、SigninLogもActivityLogも、もっとチェック項目少なかったんですよ…
ストレージアカウントの保護
AzureADログ、ActivityLog保存先に指定したことで、Blobコンテナが自動作成されています。このBlobコンテナに対して、コンテナレベルでの保護を行います。せっかく操作ログの類を取っといても、ウッカリあるいは悪意で消されてしまっては意味がありませんので、しっかり保護しましょう。
対象ストレージアカウント＞コンテナー＞個別のコンテナの設定＞アクセスポリシー、を選択し「不変Blobストレージ」を設定します。
この手のログに関しては、保存期間を指定するのが一般的でこちらは必要性に応じて設定すればよいですが、「その他の保護された追加を許可する」をチェックすることを忘れてはいけません。
（「その他の～」をつけ忘れると、ログ書き込みに失敗するので注意が必要です。）
診断設定で出力されるサインインログ、アクティビティログは、1時間ごとに新しいログファイルを作成→イベントが発生すると追記→追記という動作をする仕様上、ログファイルへの追記を許可する必要があります。これが許可されていないと、空のファイルが毎時作成されるだけになってしまい…ファイルが作成されている分たちが悪く、いざ見ようと思ったら空ファイルだったという悲劇が起きかねません。
以上に気を付けておけば、安全にログ保管ができます。
ID管理／権限管理
MFA設定
アカウント管理者はMFAを設定済み、封印することになっていました。今度は通常使うアカウントを保護する方法を考えます。
MFAを設定すること自体はベストプラクティス上も常識になっています。何処まで守るかは、その環境に置かれるデータ次第ですが、少なくとも更新権限を持つアカウントには実施し、制約が無ければ参照権限だけのアカウントでも保護したほうが良いと思います。
保護の方法は、2種類あります。（本当はもう1種類ありますが、むかーしサポートに問い合わせた際に「今後は条件付きアクセスに寄せるので、今から使うのは推奨しない」と回答もらったので、割愛します。）
セキュリティデフォルト
現在は、AzureADテナントを作成すると、最初から有効になっているので意識する必要はありません。この機能が有効だと、「全てのアカウントに対しMFA登録を必須とする」動きになります。
無償で使えるので、誰もが有効にしておくべき設定であり、これを解除することのメリットは無いと思います。
条件付きアクセス
条件付きアクセスは、認証認可において（MFAに限らず）高度な制御を行いたい場合に使用します。
例えば、接続元のIPアドレス制限や除外設定（ユーザー単位、アプリケーション単位で指定）を合わせて実施したい場合に使うことになります。MFAだけではセキュリティ的な要件を満たさない場合は、条件付きアクセスを使って実現します。
よく聞くのは「基本的にMFAを求めるけど、社内からで認証された端末を使っている場合はMFAを免除」みたいな使い方でしょうか。
条件付きアクセスは、セキュリティデフォルトと排他的にな設定となるので、要件をよく見極める必要があります。また、条件付きアクセスの制御対象となるユーザーアカウントには「AzureADのP1以上のライセンス」が必要になるので、かかるコストは最初から見込んでおきましょう。P1ライセンスを所持していないと、設定すらできません。
ユーザー作成／グループ作成
個人別にユーザーアカウントを作成、役割でグループを作成、権限はグループ単位で付与しましょうというのがベストプラクティスです。
個人別ユーザーアカウント
「管理者ユーザー」のパスワードをみんなが知ってて、みんなで共用するのはもってのほかです。人狼が混じったときに、誰の犯行か分からなくなるので、当然アンチパターン。
なお、「その端末を使った記録」などの他の仕組みと組み合わせて個人を特定できるなら共有アカウントの利用もアリかもしれません。ただし、複数ログを組み合わせて調査する必要が出てくるため、（面倒くさいので）普通は推奨されません。よって、原則的には人別でユーザーアカウントを作成しましょう。
グループでの権限付与
環境・ユーザー数の規模にもよりますが、基本的に個別のユーザーアカウントに権限を与えていくと、管理する数が増えすぎて破綻します。また、Azureの世界でも「権限の割り当て」定義にクォータが存在することもあり、ベストプラクティス通り素直にグループを作成してグループに対して権限を与えるようにすることが推奨されます。
「グループに対するAzureADロールの付与」はプレビュー機能なので、プレビュー機能なんて不安で使えないよ、という場合は一旦諦めて、個別ユーザーに対して権限を付与します。なお、このプレビュー機能は「グループ作成時」に有効にしておかないと後から有効に出来ないので注意が必要です。
「グループに対するAzureロールの付与」は特にプレビューといった制約はありませんので、確実にグループに対して権限を付与しましょう。
その他
また、ウッカリミスは誰だってするモノなので、できるだけ管理用のアカウントと日常使いの参照用アカウントは分けておいた方が良いです。ただし管理できないレベルで分けてしまって、パスワードの管理もできない…となったら本末転倒なのでほどほどにします。
改めてですが、特に「アカウント管理者」は「アカウント管理者が必要な時」以外は使用しないようにしましょう。AzureADテナントやサブスクリプションの作成レベルの作業くらいなので、小規模な環境であれば最初だけです。
ロールの設定
Azureでは、「ロールベースのアクセス制御」と言う考え方が基本にありますので、
AzureADに対するAzureADロールの設定と、サブスクリプション対するAzureロールの設定を行うことで権限を付与します。
AzureADロールはグローバル管理者が最高権限、Azureロールは所有者が最高権限ですが、安易には使わず、そのユーザーに与えるべき権限をよく見極めて設定しましょう。
なお、ロールの概念は下記のドキュメントが分かりやすいと思います。
「最小権限の原則」を考えると、必要な権限だけに絞り切ることが推奨されますが、そこまでやってられない…！と言う場合でも、最低限、閲覧権限＜更新権限＜権限を弄れる権限、の3段階くらいは検討すべきかと思います。
パスワードポリシーの設定
文字数や複雑さ、更新頻度などを設定することを推奨する時代がありました。（今もその文化は残ってますね…）
AzureADにおいては、「強力なパスワード」はデフォルトで有効であり、「有効期限ポリシー」を設定することは現在は推奨されていないため、初期設定から特に弄る必要はないと思われます。緩める必要は全くありませんが、無理に強化するよりも「確実にMFAを有効化しましょう」というのがベストプラクティスになっています。
※初出の文章がイマイチだったので訂正します。現在は「MFAを有効にすること」がベストプラクティスであるため、その代替策である「パスワード有効期限を決め、ローテーションをしましょう」というのは積極的に推奨されていません。どうしてもMFAを使えない場合を除き、特に意識しなくてよいと思います。なお、デフォルトでは「有効期限90日」となっています。
パスワードセルフリセット
（P1ライセンスを適用している環境だったら）セルフサービスパスワードリセット（SSPR）を設定することが推奨されます。一般的に、パスワード忘れの対応は何も価値を生み出さないタスクの割に、管理者にとってとても負担になりますので、できるだけユーザーセルフでできるようにしておくこと、というのが推奨事項です。
ただし、自分ひとり／数人で使うような少ない環境であればわざわざ設定するほどではないかなと思います。
環境保護
サービス正常性／リソース正常性と通知
ヘルプとサポート＞サービス正常性から、2つの通知を有効化します。
どこまでチェックを入れるかは環境の大事さと好みによりますが、概ね全ての環境で推奨できるのは
- サービス正常性は「全て」、
- リソース正常性は「Available」が「Degraded」や「Unavailable」に変化した場合
くらいはアラートを指定し、チェックした方がよいと思います。
1.サービス正常性アラートの指定
2.リソース正常性アラートの指定
いつ止まっても大丈夫…な検証環境であればそれすらやる必要はありませんが、個人のブログ運営程度でも止まったら気づきたいものです。
Security Center有効化
Free版の有効化
30日分の試用をするのは個別の検証方針などにお任せになりますが、少なくともFree版の範囲を使いだすことが推奨されます。
（検証する要件が無ければSKIPしちゃいましょう）
Free版でも、最低限必要なチェックを開始してくれて、「セキュリティスコア」を表示してくれます。リソースを作成しだす前から有効化し、定期的にチェックしていくことが大事になります。詳しくは別記事を書いていますのでそちらを読んでいただければと思います。 ※何回分かで書いているので、ぜひ遡ってみてください
連絡先の設定
Security Center＞価格と設定＞サブスクリプション＞メールによる通知、より
この設定はおそらく有償版（Azure Defender）としての設定だろうと思うんですが、Free版でももらえる通知があるかもしれないので…程度の気持ちで入力します。
Sentinel有効化（検討中）
まずActivityLogやSigninLogについては連携した方が良いでしょう。
よくある「攻撃を受けている、不穏な動きには気づけるようにしたい」あるいはAWSでいう「Rootアカウントのサインインには気づけるようにしようね」を最低ラインと考えると、
AzureADの「グローバル管理者」とサブスクリプションの「所有者」のログインには気づきましょう、というのが良いと思いますが、適当なフィルタは見当たらず…
具体的にコレは有効にしとこうね、と言う情報が世の中にあまり見当たらず、有識者の方の情報をお待ちしています！
請求
サブスクリプション請求書のDL設定
請求書をアカウント管理者以外でDLできるようにする
アカウント管理者を日常的に使わなくていいようにしておくため、本設定を行います。本設定を実施しておくことで、「請求閲覧者」などの適切なAzureロールがあれば、他のユーザーアカウントでも請求情報を参照できるようになります。
サブスクリプション＞請求書＞請求書のダウンロードを他のユーザーに許可する
からの、「オン」にして「保存」を忘れずに
メール受信設定
また、同じ画面の「請求書を電子メールで受信する」より、アカウント管理者が初期設定されていますが、必要に応じて追加しましょう。
ACM（Azure Cost Management）の設定
Budget/Alertの設定
「予算」から予算と通知を設定します。
超えたらマズいラインを設定しておいて、「思ったよりうっかり使ってしまった」や「乗っ取られて使われてしまった」に気付きやすい状況にしておくことが推奨されます。世の中のセキュリティ事故の例を見ると、「VMを立ち上げられてマイニングに使われてしまった」などもよくありますので、防ぐ／気づく手段を多重に持っておくことは大事です。
通知の段階として、予算に対する進捗率を入力する事も可能なので、何段階か設定しておくのが有効かと思います。
M365管理センターの設定
サブスクリプションの請求と、AzureAD関連のライセンス等の請求は独立しています。ここでは後者に関する通知を設定します。
請求書に関しては、サブスクリプションの方と同様に、メールで受け取れるようにすることがベターです。（能動的に見に行かないと来ない、なんていう状態だと見なくなります。そしてウッカリ請求が。アァ…）
その他
通知言語の設定・技術部連絡先設定
AzureAD＞プロパティから、「通知言語」をなじみ深いものにしておきましょう。（デフォルトがEnglishなので、日本語にしておきたい。）
普段、Englishのまま受けていないので、どれくらい分かりづらいのかわかりませんが…。
また、技術部連絡先は初期設定だとアカウント管理者のアドレスになっているはずです。これも、情報を受け取るべき人に変更しておいた方が良いでしょう。
連絡用メールアドレスの設定
作成した管理者アカウントに対して、「連絡先メールアドレス」を設定しておきます。
※空の例です。良くない。「編集」から入力しましょう。
Azureの仕様上、「管理者に通知する」となっている設定箇所があり、メールアドレスを設定しておかないと通知が来ないためです。
例えば「Azure Defender for SQLの脅威検知の通知先」などで「サブスクリプションの所有者」といった通知先設定が出てきますので、管理者アカウントに対しては連絡先メールアドレスを正しく設定しておくことが重要です。
Azure Advisorの設定
全般
サポートレベルに関係なく、チェックしてくれます。（AWSのTrusted Advisorはサポートレベルによってチェック範囲がちがいますので、考え方の違いに注意です）
様々な設定項目に対する推奨事項を提示してくれる機能なので、定期的に見るとよいと思います。
アラートの設定（プレビュー）
定期的に画面上でチェックするだけでなく、新たに推奨事項にひっかかるリソースが検出された場合に通知を貰えるように構成できます。
推奨事項のレベル「高」などは、通知を入れるとよいと思います。全部にチェックを入れると、きっとオオカミ少年になってしまい見なくなってしまうので、ほどほどが重要です。
徐々に推奨事項の低いレベルまで対応していきましょう。
おわりに
一通り、思いつく限りで書き切りました。
1回で満点取れる気はしていないので、議論が起こったらいいなと思って書いていますので、お気づきの点あればぜひコメントください！
Discussion
後から気づいたやるべきことを追記①
Azureの予算アラート（コストアラート）を設定する
後から気づいたやるべきことを追記②
Azure使いだすときにSentinelでやっておくべきこと
※後から気づいたと言うか、検討を後回しにしたというか…