【備忘録】AZ-500の勉強

AZ-500の勉強の備忘録です。

【ストレージ】
・ユーザがSQL DBにログを送れるようにするには？
 1.SQLDB用のAzureAD管理者権限を付与
 2.SQL Server management Studio(SQLの管理統合環境)経由でSQL DBにアクセスする
 3.データベースユーザを作成する。
 普通はログインユーザでSQLサーバにアクセスして、その中身のDBをみるのはデータベースユーザがやる。
 ↑は同じことをやっているだけ。
 ※ストレージアカウントとDBはロケーション同じならログ取れる。リソースグループは違ってもOK。


・AzureStorageAccountがある。
 blobサービスを使えるのはShared Key＝StorageAccountKey、SAS、AzureAD。
 AzureFile(SMB)サービスを使えるのはShared Key、AzureAD。
 AzureFile(REST API)サービスを使えるのはShared Key、SAS。
 Tableサービスを使えるのはShared Key＝StorageAccountKey、SAS、AzureAD。
 ストレージサービスを使う権限はどうやって決める？一時的、アカウントに付与。


【監視】
・VMでユーザの権限をみるにはどこをみる？
 azure monitorのアクティビティログ。90日保存される。Log Analyticsに送信可能。


・Azureの監視手法の分類
 Service Health         :MSのサービス情報がでる。なんか設定変わったとか、それでどんな影響でそうかなど。
 Monitor                                :VMやリソースのメトリック、アクティビティログとかを集計、可視化する。
 Advisor                                :推奨構成とかを教えてくれる。推奨されてない設定になってますよ～とか教えてくれる。
 Log Analytics                  :監視データが集まっていれば、それをクエリとして処理できる。アラートの発令とかのトリガーになれる
 Application Insight    :アプリレベルのMonitor、Advisorって感じ。他サービスは4層以下かな。


 Microsoft Defender for Cloud   ：総合監視。セキュリティスコア、コンプラ違反などに対応。CASB。
 ※CASB:クラウドシステムへのアクセス状況、その通信内容の監視を行い、ポリシーに反していたらブロックしたりするソリューション。端末（VDIも含む）とSaaSの間にいるイメージ。VNwtworkには適用不可。脅威の検出にはKustoクエリーを使う。
 Microsoft Defender for SQL     ：DB版であり、脆弱性の検出やスコアリングしてくれる。SQLインジェクションなどから防御する。


・Microsoft Defender for Cloudはコンテナレジストリ内のイメージの脆弱性にアドバイザリをくれる。今はWindowは対応していない
【グルーピング】
管理グループ（人事部、IT部など）＞サブスク（ミッションクリティカル、保護されたデータなど）＞リソースグループ（ライフサイクルが同じもの）


・管理グループ
 サブスクをグループ化できる。つまり、管理グループにポリシーを適用すれば、その配下のサブスクにも適用できる。
 ミラー化できる。会社の組織を似たように作成できる。


・リソースグループ
 同じライフサイクルのもの。
 各リソース：リソースグループは1:1。リソースのリソースグループ間移動は可能。また、リージョンも超えてＯＫ。
 key vaultは同じリージョンなら使用可能。リソースグループは関係ない。


・静的グループに動的グループをネストすることは可能


・エンタープライズアプリケーションはM365グループに含むことはできない。エンタープライズアプリケーションはエンティティじゃないから？
・マネージドIDはM365グループに含むことはできない。


・マネージドIDに関しては以下を参照
https://qiita.com/Shinya-Yamaguchi/items/edd75f7ee47471a98670


【IDガバナンス】
エンタイトルメント管理                     ：組織が ID とアクセスのライフサイクルを大規模に管理できるようにする ID ガバナンス機能です。アクセス要求ワークフロー、アクセス割り当て、レビュー、および有効期限が自動的に管理されます。
Azure AD アクセス レビュー              ：
Azure AD の使用条件                          ：データまたはアプリケーションにアクセスする前に、ユーザーに確認する機能
以下はAzureADPremium2でしか提供していない。
Privileged Identity Management  ：「重要なリソースへのアクセスには承認が必要」など特権IDの管理・制御・監視するAzureADのサービス。
Azure Identity Protection               ：アクセスレビュー機能。AzureAD、特権ID、アプリでそれぞれ作成できる。
                                                                 MFAなどの条件付きアクセス機能。(=リスクベース認証)


※条件付きアクセスとは、場所、アプリの種類、リスクをIF文で分岐させ、対応（許可、ブロック、MFAなど）を決めてアクセスさせるやり方。


・コンプラ違反しているVMを洗い出したい
 Microsoft Defender for Cloudにポリシーorイニアティブを追加すればＯＫ。


 ・BluePrintとは？
 BPは環境全体の作成を自動化。やることは、サブスクに対してリソースグループを作成、ARMテンプレを利用してリソースを作成、それらにロール（リソースに対してできること、できないこと）とポリシー（リソース作成でやってはいけないこと）を割り当てる。
 ・BluePrintとARMテンプレートの違い
 サブスクやリソースグループを何個も立てる   →BP
 VMを何個も立てる                                                      →ARMテンプレート
 定義された箇所にしか新しく作れない。Sub1で定義したblueprintで生み出せる先は、Sub1のみ。


・Azure Automation
 クラウド環境で発生する運用タスクを自動化するサービス。
 以下がそのサービス例。
 ・update management
  OSの自動更新機能。VMやオンプレのマシン(エージェント入り)が対象。
  windows、LinuxどっちでもグルーピングはOKだが、WindowsグループならWindowsVMのみになる。


【AzureAD】
・Azure Identity Protection                     


・Privileged Identity Management
 PIM使えるようになったら、以下が考えられる。
  Just-in-time（時間制限付き）特権アクセスによる運用者のアクセス。
  そのアクセスには承認が必要だったり、その承認には多要素認証が必要だったりできる。
  アクセス権がアクティブになった際の通知もとばせる


・「委任されたアクセス許可」と「アプリケーションの許可」の違い
 前者は指定したユーザーの権限でAPIを使用する、後者はAzureADアプリに設定した権限でAPIを使用する


・グループとメンバーシップ
 グループは2種類
  セキュリティG       ：ユーザとデバイスのリソースのアクセス管理用。AzureADでRBAC付与とかはこっち。消すと復元不可能。
  Microsoft365G ：ユーザの共有リソース（Teamsのチームとか）のアクセス管理用。


 メンバーシップは3種類
  割り当て済み        ：手動で割り当てる。
  動的ユーザ         ：メンバーシップルールで自動割り当て。ユーザの属性から判定し、追加削除する。
  動的デバイス        ：↑のデバイスバージョン。
 ※メンバーシップは3種類の中から1つのみ。デバイスとユーザを同時にはできない。
  デバイスＧとユーザＧを2つ作成して、その２Ｇを１つにまとめる方法をとろう。


・Just-in-time Access
 仮想マシンへの接続を最小限にする。基本的に全受信トラフィックを拒否している。
 Security center（セキュリティのスコアやアドバイスもらうセキュリティシステム）でAzureDefenderを有効にする
 JItを有効化し、そこにVMを追加する


・条件付きアクセス。AzurePremium1以上で利用可能。
 以下の順番で判断する。IF文。
 1.Who are you?(ユーザ及びグループ)
 2.What do you use?(SP)
 3.詳細（どこからアクセスしたかなどリスクベース）
 3まで終わった後に「ブロック」、「アクセス権」、「セッション」のどれかを与える。


・アプリケーションがMSのサービスを利用できるようにするには？
 1.AzureADでアプリをオブジェクトとして登録
 2.アプリ用の権限作成
 3.その権限をオブジェクトに付与


【Key Vault】
・ベストプラクティス
 管理プレーンとデータプレーンで分ける。用途によって、アプリやユーザにそこにアクセスできるRBACorキーコンテナアクセスポリシーを付与する。
 VM作成時に証明書を付与。その証明書はコンテナで管理するため、アクセス制御が楽になる。
 コンテナ（及びその中身）は回復可能。保護機能を有効にしておけば。


・Key Vaultへのアクセス方法
 認証：両方のプレーンでAzureADが使用される。セキュリティプリンシパルを（AzureAD上のユーザ、アプリなどのオブジェクトと紐づく）使う。AzureADに登録しないと認証できない。
 認可：管理プレーンではRBAC、データプレーンではKey vaultアクセスポリシーorデータプレーン用RBAC。


 1、2を通って初めて、アクセスできる。
 1. AzureADで認証する
 2. 認可する
        金庫（Vault）自体の変更をしたい              →RBAC
        金庫内の鍵を取り出したい                    →Key Vaultサービスのアクセスポリシー（or RBAC）
        https://www.purin-it.com/azure-key-vault-1


・Key Vaultの構成
 管理プレーン         ：Key vault（金庫）自体の管理。
 データプレーン        ：金庫内のデータ（まじもんのシークレットPWとか証明書とか）


・key vaultの複製を置ける条件
 同じリージョンかつ同じサブスクリプションであること。


・Keyの復元
 soft-deleteを有効にしておくと、削除後も〇日後まで復元可能。そいつが残っている間は、同じ名前のものは作成できない


・KeyでVMのディスクを暗号化する条件
 ロケーションが同じならできる。リソースグループは関係ない。
 1.キーボールトアカウントを作成
 2.キーボールトのアクセスポリシー設定


・Standard と Premium の主な違い
→保存されたシークレットにHSM機能が使えるかどうか


・Log Analytics workspaceがVMから情報取得できる条件
 ロケーション、リソースグループ関係ない。マネージドサービスだからかな？（推測）


・暗号化されたDBにアプリがアクセスして、そのデータを利用するには？
 カラム（列）暗号化キーと復号化キーが必要。


【Sentinel】
・Microsoft Sentinel の概要
 クラウドネイティブなSIEM（セキュリティ情報イベント管理）かつSOAR（セキュリティオーケストレーション自動応答）サービス
 SIEM機能（セキュリティ情報イベントを収集・検出するマネジメント機能）とSOAR機能(それらをAIで調査し、アクションする)


・Sentinel をデプロイ
 1.LogAnalyticsワークスペースを作成
 2.Sentinelワークスペースが存在するサブスクの共同作成者がSentinelを有効にする
 3.ワークスペースが属するリソースグループの共同作成者or閲覧者が必要。←これないとワークスペースにアクセスできず、ログの収集・分析ができない
 4.データを Microsoft Sentinel に接続
  Azureのメイン機能は最初から接続可能(Azure ログ、Azure AD、AWS Cloudtrail など)
  上記以外の外部アプライアンス、例えばオンプレのマシンなどには直接エージェントを入れる、もしくは、エージェントを入れたマシンを経由して(Syslog)ログを送る。


・悪意のあるＩＰアドレスを後から見つけるには？
 Sentinel workspace(MSのSIEM(セキュリティ情報イベント管理)兼SOAR(セキュリティオーケストレーション自動応答))からLogAnalyticsでクエリを流す。
 クエリの結果を確認して、ブックマークに追加する。