Microsoft Sentinel unified RBACの要点は、SOCチームのアクセス範囲を「ワークスペース単位」だけで分けるのではなく、Microsoft Defenderポータル上のUnified RBACとスコープ、さらに行レベルのタグ付けで細かく制御できるようになる点です。これにより、地域別SOC、事業部別SOC、MSSP、外部監査チームなどが同じMicrosoft Sentinel環境を共有しながら、必要なインシデント・アラート・ログだけを扱いやすくなります。
一方で、導入すれば自動的に最小権限が完成するわけではありません。Microsoft SentinelワークスペースのDefenderポータルへのオンボード、Unified RBACの有効化、対象テーブルの確認、KQL検出ルールでのSentinelScope_CFの扱い、既存Azure RBACとの役割分担を整理してから展開する必要があります。特に「過去データは後からスコープ付けされない」「一部ロールやサービスプリンシパルはUnified RBACで未対応」という制約は、移行計画に直接影響します。
Microsoft Sentinel unified RBACで何が変わるのか
Microsoft Sentinel unified RBACは、Microsoft Defenderポータルを中心に、Microsoft Sentinelの権限管理をより一貫した形で扱うための仕組みです。Microsoft Learnでは、Microsoft Defender unified RBACが複数のセキュリティソリューションにまたがる権限管理の中心として説明されており、Microsoft Sentinelも対象サービスに含まれています。Microsoft Sentinelでは、Defenderポータルにオンボードされたワークスペースに対するアクセス管理をUnified RBACで扱えるようになります。(Microsoft Learn)
従来のMicrosoft Sentinel運用では、アクセス分離の単位としてLog Analyticsワークスペースやリソースグループ、Azure RBACロールを強く意識する必要がありました。たとえば「欧州SOCには欧州拠点のログだけ見せたい」「子会社Aのインシデントを子会社Bの担当者に見せたくない」といった要件では、ワークスペース分割や複雑な運用設計になりがちです。
今回の重要な変化は、Microsoft Sentinel scoping、つまりrow-level RBACを使って、同じMicrosoft Sentinel環境内でもデータ行単位に近い粒度でアクセスを絞れるようになることです。Microsoft Learnでは、scopingによりワークスペースを分けなくてもSentinelデータの特定サブセットに対するアクセス制御が可能になり、管理者は論理スコープを定義し、取り込み時にデータへタグを付け、Unified RBACでユーザーやグループへスコープを割り当てられると説明されています。(Microsoft Learn)
実務的に言えば、SOCの権限設計は次のように変わります。
| 観点 | 従来寄りの考え方 | unified RBACとscoping後の考え方 |
|---|---|---|
| アクセス分離 | ワークスペース、リソースグループ、Azure RBACで分ける | DefenderポータルのUnified RBACとSentinel scopeで分ける |
| 複数SOCの共同運用 | チームごとにワークスペースを分ける設計になりやすい | 共有ワークスペース内で担当範囲ごとにデータを見せ分ける |
| 最小権限 | ロール単位では実現できても、データ範囲の分離が難しい | ロールの操作権限とデータスコープを組み合わせて制御する |
| 管理画面 | AzureポータルとDefenderポータルをまたぐ | Sentinel権限はDefenderポータル側で管理する比重が増える |
| 注意点 | ワークスペース分割の運用負荷 | スコープ設計、タグ付け、未対応ロール、既存権限との重複に注意 |
対象になる管理者・SOCチーム・開発者
この変更の影響を受けるのは、Microsoft Sentinelを単独のSIEMとして使っている組織だけではありません。Microsoft Defender XDR、Microsoft Sentinel data lake、Advanced hunting、SOARプレイブック、MSSP運用を組み合わせている組織ほど、権限モデルの見直しが重要になります。
特に確認すべき対象者は次の通りです。
| 対象者 | 確認すべきこと |
|---|---|
| Microsoft Sentinel管理者 | ワークスペースがDefenderポータルにオンボード済みか、Unified RBACを有効化する単位をどうするか |
| SOCマネージャー | Tier 1、Tier 2、地域SOC、事業部SOC、外部委託先ごとの閲覧・対応範囲 |
| セキュリティアナリスト | 自分のスコープで見えるアラート、インシデント、ハンティング結果が業務に足りるか |
| 検出ルール開発者 | カスタム検出のKQLでSentinelScope_CFを投影しているか |
| SOAR/Logic Apps担当者 | プレイブックや自動化ルールの権限がUnified RBACだけで完結しないケース |
| IAM/Entra ID管理者 | Entraロール、Azure RBAC、Unified RBACの重複による過剰権限 |
| MSSP/マルチテナント運用担当 | GDAP、サービスプリンシパル、Azure Lighthouseなど既存の委任アクセス設計 |
Microsoft Learnでは、Unified RBACでMicrosoft Sentinelを有効化するには、Microsoft Entra IDのSecurity Administratorに加え、Subscription Owner、またはUser Access AdministratorとSentinel Contributorの組み合わせが必要とされています。また、Global Administratorであってもワークスペースへの自動権限が付与されるわけではなく、自分自身を含めて権限を割り当てる権利を持つ、という位置づけです。(Microsoft Learn)
scopingの仕組みを実務目線で理解する
Microsoft Sentinel scopingは、次の3つを組み合わせてアクセス範囲を決めます。
- 論理スコープ：地域、事業部、顧客、機密区分など、組織のアクセス境界を表す名前
- ユーザーまたはグループへの割り当て：Unified RBACロールに対して、どのスコープを使えるかを設定
- 取り込み時のデータタグ付け：テーブルの行にスコープタグを付け、対象ユーザーに見えるデータを制限
Microsoft Learnでは、スコープはDefenderポータルのSystem > Permissionsから作成し、ユーザーまたはグループ、データソース、データコレクション、Sentinelワークスペースと関連付けます。ユーザーは複数のスコープに同時に割り当てられ、アクセス権は割り当てられたスコープの合算として扱われます。(Microsoft Learn)
たとえば、グローバル企業で次のような運用をしているケースを考えます。
| スコープ名 | 想定ユーザー | 見せたいデータ |
|---|---|---|
JP-SOC | 日本SOCチーム | 日本拠点のログ、アラート、インシデント |
EU-SOC | 欧州SOCチーム | 欧州拠点のログ、アラート、インシデント |
PCI-Scope | 決済システム担当SOC | PCI対象システムのセキュリティデータ |
Network-Ops | ネットワーク運用チーム | ネットワーク機器ログの一部 |
MSSP-Customer-A | 外部SOC事業者 | 顧客Aに関係するデータのみ |
この設計では、ワークスペースを細かく分割しなくても、各チームが同じSentinel環境の中で自分の担当範囲だけを調査できます。SOC運用では「全員にReaderを付ける」よりも、初動対応者には担当範囲のインシデント管理だけを許可し、検出ルールやプレイブックの変更は上位担当者に限定する、といった分離がしやすくなります。
管理者が最初に確認すべき設定
導入前にまず確認すべきなのは、機能そのものよりも「前提条件を満たしているか」です。scopingはDefenderポータルで構成する機能であり、Microsoft SentinelワークスペースがDefenderポータルにオンボードされ、Microsoft SentinelがUnified RBACで有効化されている必要があります。さらに、スコープやテーブルタグ付けを行う担当者には、Security Authorization、Data Operations、DCR作成に関係する権限が必要です。(Microsoft Learn)
確認ポイント
| 確認項目 | 見る場所・観点 | 不備がある場合の影響 |
|---|---|---|
| Defenderポータル利用可否 | security.microsoft.comにアクセスできるか | scopingの設定画面に進めない |
| Sentinelワークスペースのオンボード | Defenderポータル上で対象ワークスペースが見えるか | Unified RBACやscopingの対象にできない |
| Unified RBACの有効化 | ワークロード設定でSentinelが有効か | Sentinel scopeを使った制御ができない |
| 管理者権限 | Security Administrator、Subscription Ownerなど | 有効化やロール割り当てで失敗する |
| 対象テーブル | ingestion-time transformations対応か | 行レベルタグ付けができない |
| 既存Azure RBAC | Reader、Contributor、Sentinelロールの棚卸し | スコープより広い権限が残る可能性 |
| 自動化・プレイブック権限 | Logic Apps、Playbook Operator、Automation Contributor | Unified RBACだけで移行できない部分が残る |
Microsoftの有効化手順では、System > Permissions > Microsoft Defender XDR > Rolesからワークロードを有効化でき、Microsoft Sentinelについては対象ワークスペースを選択して有効化します。別ルートとしてSystem > Settings > Microsoft Defender XDR > Permissions and rolesからも有効化できます。(Microsoft Learn)
導入手順の全体像
実際の展開では、いきなり全SOCへ展開せず、小さなデータ範囲でパイロットするのが安全です。Microsoft Learnでも、次のステップとして「対応テーブルの確認」「スコープ名とロジックの計画」「小さなチームまたはデータサブセットでのパイロット開始」が推奨されています。(Microsoft Learn)
推奨する進め方
| 手順 | 作業 | 実務上の判断基準 |
|---|---|---|
| 事前棚卸し | 既存のAzure RBAC、Sentinelロール、Entraロール、グループを洗い出す | 「誰が何を見られるか」を現状表にする |
| スコープ設計 | 地域、事業部、顧客、データ機密度などで分ける | 100個以内に収まる粒度にする |
| 対象テーブル確認 | ingestion-time transformations対応テーブルを確認 | 主要ログが対象外なら別設計を検討 |
| Unified RBAC有効化 | 対象ワークスペース単位で有効化 | まず検証用ワークスペースまたは限定チーム |
| カスタムロール作成 | 操作権限とスコープを組み合わせる | Reader相当、Responder相当、管理者相当を分ける |
| スコープタグルール作成 | KQL式で対象行を選び、スコープを付ける | 条件漏れ、重複、未スコープ行をテスト |
| 検出ルール確認 | SentinelScope_CFを投影する | scoped analystにアラートが見えるか検証 |
| 運用テスト | アラート、インシデント、ハンティング、lake探索を確認 | 想定より見えすぎないか、見えなさすぎないか |
| 本番展開 | グループ単位で段階的に割り当て | ロールバック手順と問い合わせ先も用意 |
データのタグ付けで注意すべきこと
scopingのアクセス制御は、取り込み時にデータへスコープタグを付けることで実現します。Microsoft Learnでは、Microsoft SentinelのConfiguration > Tablesから、ingestion-time transformationsをサポートするテーブルを選び、Scope tag ruleを設定すると説明されています。タグ付けはData Collection Rule、つまりDCRを作成して新しく取り込まれるデータに適用されます。(Microsoft Learn)
ここで重要なのは、過去に取り込まれたデータには後からスコープが付かないことです。Microsoft Learnでは、スコープタグは新しく取り込まれたデータに適用され、以前に取り込まれたデータは含まれないとされています。また、ルール保存後に有効になるまで最大1時間かかる場合があります。(Microsoft Learn)
失敗しやすい設計例
| 失敗例 | なぜ問題か | 対策 |
|---|---|---|
| 過去データも自動的に制限されると思い込む | 既存ログはretroactiveにスコープ付けされない | 展開日以降のデータから制御される前提で説明する |
| テーブル単位で制御できると思い込む | 対象はingestion-time transformations対応テーブルに限られる | 対象テーブルを先に確認する |
| 条件式が曖昧 | 意図しないデータが未スコープまたは別スコープになる | 代表ログでKQL条件を検証する |
| スコープ名を組織名そのままにする | 組織改編で破綻しやすい | 地域、機能、データ分類など長期的な軸で命名する |
| 全社展開から始める | 見えないインシデントやアラートが発生しても切り分けにくい | 小さなチーム、単一テーブル、限定期間で試す |
スコープタグルールのKQLは、できるだけ監査しやすく書くべきです。たとえば地域で分けるならLocation == 'Japan'のような単純な条件が理想です。複数の列や曖昧な文字列一致に依存すると、ログ形式の変更で意図しないスコープ漏れが発生します。
インシデントとアラートの見え方はどう変わるか
scoped userは、割り当てられたスコープに基づいてSentinelのデータにアクセスします。Microsoft Learnでは、scoped userはスコープ内データから生成されたアラートを表示でき、アラートに紐づくすべてのイベントへアクセスできる場合に管理できます。インシデントについては、少なくとも1つのスコープ内アラートを含む場合に表示でき、管理するには基礎となるすべてのアラートにアクセスでき、必要な権限を持っている必要があります。(Microsoft Learn)
つまり、SOCの現場では次のような見え方になります。
- JP-SOC担当者は、日本拠点にスコープ付けされたアラートを見られる
- 複数地域のアラートを含むインシデントは、一部だけ見える可能性がある
- インシデントを管理するには、関連する全アラートへのアクセスと操作権限が必要
- スコープ外のエンティティは見えない場合がある
- 権限不足により「存在するはずのアラートが見えない」ケースが起きる
これはセキュリティ上は望ましい挙動ですが、SOC運用では混乱を生みやすいポイントでもあります。特にTier 1が一次切り分けを行い、Tier 2が横断調査を行う組織では、Tier 2には複数スコープを割り当てる、またはエスカレーション時に広いスコープを持つロールへ切り替える運用を検討すべきです。
カスタム検出ルールではSentinelScope_CFを確認する
開発者や検出エンジニアが必ず確認すべきなのが、カスタム検出ルールのKQLです。Microsoft Learnでは、SentinelScope_CFカスタムフィールドをクエリや検出ルールで使えると説明されています。また、カスタム検出や分析ルールを作成する場合、トリガーされたアラートをscoped analystに表示させるには、KQLでSentinelScope_CF列をprojectする必要があります。投影しない場合、アラートはunscopedとなり、scoped userから非表示になります。(Microsoft Learn)
これは移行時の落とし穴です。既存の検出ルールが正常に動いていても、スコープ対応後に担当アナリストからアラートが見えなくなる可能性があります。
確認すべきKQLの観点
| 確認対象 | チェック内容 |
|---|---|
| カスタム分析ルール | 最終出力にSentinelScope_CFを含めているか |
| joinを使うルール | join後にスコープ列が落ちていないか |
| summarizeを使うルール | 集約後にスコープ情報をどう保持するか |
| unionを使うルール | 複数テーブル間でスコープ列の有無を吸収できるか |
| watchlist参照 | watchlist側の情報でスコープ判定を上書きしていないか |
| automation rule連携 | アラートが見えるユーザーと自動化実行権限が一致しているか |
たとえば、集約系の検出では、単純にsummarize count()してしまうとスコープ情報が失われる可能性があります。スコープ単位でアラートを分けたいなら、SentinelScope_CFを集約キーに含める、または出力列として残す設計を検討します。
既存のAzure RBACとの関係
Microsoft Sentinel unified RBACは、Azure RBACを完全に無視してよいという意味ではありません。Microsoft Learnでは、Microsoft Sentinel SIEMではAzure RBACの組み込みロールとカスタムロールが使われ、Microsoft Sentinel data lakeではMicrosoft Entra ID RBACやDefender XDR unified RBACが関係すると説明されています。(Microsoft Learn)
また、Unified RBACを有効化した後は、Microsoft Sentinel権限管理をDefenderポータル側で行うことが推奨されます。Azureポータルで権限変更を行うと同期エラーにつながる可能性があり、問題が起きた場合はDefenderポータルのPermissionsページに通知が表示されます。(Microsoft Learn)
特に注意したいのは、権限は累積されるという点です。Microsoft Learnでも、ユーザーが複数ロールを持つ場合、意図より広い権限になる可能性があると説明されています。(Microsoft Learn)
移行時に棚卸しすべき権限
| 権限の種類 | 例 | 確認理由 |
|---|---|---|
| Azure RBAC | Owner、Contributor、Reader、Microsoft Sentinel Reader/Responder/Contributor | スコープより広い閲覧権限が残る可能性 |
| Log Analyticsロール | Log Analytics Reader、Log Analytics Contributor | Sentinel外のワークスペースデータも見える可能性 |
| Microsoft Entraロール | Security Reader、Security Operator、Security Administrator、Global Reader | data lakeやDefender側で広いアクセスになる可能性 |
| Unified RBACロール | Security data、Alerts、Authorization、Data operations系のカスタム権限 | Defenderポータル上の操作範囲を決める |
| Logic Apps関連 | Logic App Contributor、Playbook Operator | SOAR運用では別リソース権限が必要 |
| サービスプリンシパル | 自動デプロイ、CI/CD、IaC、外部連携 | Unified RBAC未対応のケースがある |
対応していない・注意が必要な範囲
Unified RBACとscopingは強力ですが、すべてのMicrosoft Sentinel運用を置き換えるものではありません。Microsoft Learnでは、Microsoft Sentinel Playbook Operator、Automation Contributor、Workbook ContributorはUnified RBACでサポートされず、Azure側で引き続き管理すると説明されています。また、Microsoft SentinelでサービスプリンシパルやGDAPユーザーグループへ権限を割り当てることはUnified RBACでサポートされないため、必要な場合はAzure RBACを使い続けるよう案内されています。(Microsoft Learn)
scoping側にも制約があります。Microsoft Learnでは、過去データはスコープ付けされず、ingestion-time transformations対応テーブルのみタグ付け可能、Custom tableのCLv1は非対応、CLv2は対応、XDRテーブルは非対応、Sentinel in Azure portalではscopingをサポートしないとされています。(Microsoft Learn)
| 制約 | 実務上の影響 | 対応策 |
|---|---|---|
| 過去データはスコープ付け不可 | 移行日前のログは同じ制御にならない | 展開日を明確にし、必要ならワークスペース分離や別管理を継続 |
| 対応テーブルが限定される | 主要ログがスコープ対象外の場合がある | 事前に対象テーブルを確認 |
| XDRテーブルは対象外 | Defender XDR由来データの見え方は別設計が必要 | Defender側の権限設計と合わせて確認 |
| Sentinel Azureポータルでは非対応 | Azureポータル前提の運用では使えない | Defenderポータル運用へ移行 |
| Playbook Operatorなどは未対応 | SOAR権限がUnified RBACに集約されない | Azure RBACとLogic Apps権限を文書化 |
| サービスプリンシパル権限割り当て未対応 | CI/CDや自動管理に影響 | Azure RBAC継続、または設計見直し |
| スコープは最大100個 | 顧客・部署ごとに細かく切りすぎると上限に近づく | 命名規則と粒度を先に決める |
SOCチームの権限設計で使える判断基準
Unified RBACとscopingを設計する際は、「誰に何を見せるか」だけでなく、「誰に何を変更させるか」を分けて考えることが重要です。
閲覧範囲と操作範囲を分ける
SOCでは、次の2軸で権限を設計すると破綻しにくくなります。
| 軸 | 例 | 設計の考え方 |
|---|---|---|
| データ範囲 | 日本、欧州、顧客A、PCI対象、ネットワークログ | Sentinel scopeで制御 |
| 操作権限 | 閲覧、インシデント管理、検出ルール変更、プレイブック実行 | Unified RBAC、Azure RBAC、Logic Apps権限で制御 |
たとえば、Tier 1アナリストには「JP-SOCスコープのインシデント閲覧・管理」、検出エンジニアには「複数スコープのログ閲覧と検出ルール編集」、SOCリーダーには「複数地域のインシデント管理」、外部監査チームには「特定テーブルの読み取りのみ」を付与します。
スコープ名は人事組織ではなく運用境界で決める
スコープ名を部署名そのままにすると、組織改編で運用が壊れます。おすすめは、長期的に変わりにくい境界で命名することです。
| 避けたい命名 | 推奨しやすい命名 |
|---|---|
Tanaka-Team | JP-SOC |
Dept-2026-A | Finance-Systems |
Project-X-Temp | High-Sensitivity |
Customer-OldName | MSSP-Customer-001 |
ただし、スコープが抽象的すぎると監査時に説明しにくくなります。スコープ定義には、対象データ、担当グループ、業務目的、オーナー、レビュー周期を必ず残しておくべきです。
開発者・自動化担当者が確認すべきこと
検出ルールや自動化を開発しているチームは、Unified RBACを単なる管理画面変更として扱うと失敗します。データの見え方が変わるため、KQL、検出ルール、Logic Apps、CI/CD、IaCテンプレートの確認が必要です。
KQLと検出ルール
SentinelScope_CFを落とさないことが最重要です。特に、既存ルールをコピーして別チーム向けに展開している環境では、ルールごとの出力列を棚卸ししてください。
確認例は次の通りです。
- カスタム検出ルールの最終出力に
SentinelScope_CFがあるか project-awayでスコープ列を削除していないかsummarize後にスコープ単位が混ざっていないかjoinやunionでスコープ列名が変わっていないか- アラート生成後、対象スコープのアナリストに見えているか
Logic Appsとプレイブック
プレイブックはAzure Logic Apps上の別リソースです。Microsoft Sentinelのインシデントが見えることと、Logic Appsを実行・編集できることは同じではありません。Microsoft Learnでも、プレイブックの実行や作成にはMicrosoft Sentinel Playbook OperatorやLogic App Contributorなど、追加ロールが関係すると説明されています。(Microsoft Learn)
移行時は、次のように整理します。
| 自動化対象 | 確認ポイント |
|---|---|
| インシデントトリガーのプレイブック | 実行アカウントが対象リソースグループに明示的な権限を持つか |
| 手動実行プレイブック | アナリストがプレイブックを見つけて実行できるか |
| automation rule | ルールを管理できる権限とプレイブック実行権限が分離されているか |
| CI/CD | サービスプリンシパルが必要なAzure RBAC権限を持つか |
| 監査ログ | 権限変更と自動化実行を追跡できるか |
移行時のリスクと回避策
Unified RBACの導入で最も避けたいのは、「権限を絞ったつもりが広く見えている」または「本番インシデントが担当者に見えない」という状態です。どちらもSOC運用では重大な問題になります。
リスク別チェック表
| リスク | 起きる原因 | 回避策 |
|---|---|---|
| スコープ外データが見える | Azure RBACやEntraロールで広い権限が残っている | 既存ロールを棚卸しし、広域ロールを最小化 |
| インシデントが見えない | 関連アラートがunscoped、またはSentinelScope_CFがない | 検出ルールの出力列を修正 |
| 過去データが想定と違う | スコープは新規取り込みデータだけに適用 | 展開日以降の制御として運用説明 |
| プレイブックが動かない | Logic Apps側の権限が不足 | SOAR関連ロールを別途確認 |
| Azureポータル変更で同期エラー | Unified RBAC有効後にAzure側で権限変更 | 権限変更ルートをDefenderポータルに統一 |
| MSSP運用で委任アクセスが詰まる | GDAPユーザーグループやサービスプリンシパルが未対応 | Azure RBAC継続やB2B運用を含めて設計 |
| スコープが増えすぎる | 顧客、部署、環境単位で無計画に作成 | 命名規則と作成承認プロセスを設ける |
本番展開前に行うべきテスト
本番展開前には、少なくとも次のシナリオをテストしてください。
| テスト | 確認内容 |
|---|---|
| スコープ内ログの閲覧 | 対象ユーザーがAdvanced huntingやSentinel lakeで想定データだけ見えるか |
| スコープ外ログの非表示 | 他地域・他顧客・他事業部のログが見えないか |
| アラート表示 | スコープ内データから生成されたアラートが見えるか |
| インシデント管理 | 関連アラートの一部だけ見える場合の操作可否 |
| カスタム検出 | SentinelScope_CFを含むルールでアラートが正しく表示されるか |
| プレイブック実行 | 手動実行、自動実行、権限不足時の挙動 |
| 権限昇格 | PIMなどを使う場合、昇格後に必要なスコープ・操作が使えるか |
| ロールバック | Unified RBAC無効化時に以前の権限モデルへ戻せるか |
テスト用ユーザーは、管理者アカウントではなく実際のSOCロールに近い一般ユーザーで作ることが重要です。管理者アカウントで見えるからといって、Tier 1アナリストにも同じように見えるとは限りません。
いま取るべきアクション
Microsoft Sentinel unified RBACは、SOCチームの最小権限設計を現実的にする重要な変更です。特に、複数のSOCチーム、地域別運用、MSSP、外部監査、機密データ分離を抱える組織では、ワークスペース分割だけに頼らないアクセス設計がしやすくなります。
ただし、成功の鍵は「有効化」ではなく「設計」です。まずは次の順番で進めるのが現実的です。
- 既存のAzure RBAC、Entraロール、Sentinelロール、Logic Apps権限を棚卸しする
- SOCの担当範囲を、地域・事業部・顧客・機密度などのスコープに整理する
- 対象テーブルがingestion-time transformationsに対応しているか確認する
- 検証用スコープを作り、少人数のSOCチームでパイロットする
- カスタム検出ルールで
SentinelScope_CFを確認する - SOAR、プレイブック、CI/CD、サービスプリンシパルの権限を別途確認する
- 本番展開後も、権限レビューとスコープレビューを定期的に行う
Microsoft SentinelをDefenderポータル中心で運用していく組織にとって、unified RBACとrow-level scopingは避けて通れない設計テーマです。最初から全社展開を狙うより、限定スコープで「見えるべきものが見える」「見えてはいけないものが見えない」ことを確認しながら、段階的にSOC全体へ広げていくのが安全です。
コメント