top of page

第二部:例外申請の迷宮(承認フローとLogic Apps)

――『青の契約(Der blaue Vertrag)』続篇(Faust風)

配役追加

  • ロジカ:迷宮そのもの(Azure Logic Appsの擬人化)。糸を引き、分岐し、待ち、再び動く。

  • デナイの門番:拒絶の役人(Azure Policy “Deny” の寓意)。

  • 免除(エグゼンプト)の札係:Policy Exemption の書記。

  • チームズの使者:Teams の青い鳥。承認の札を運ぶ。

  • 砂時計:expiresOn(期限)の寓意。

序幕 「拒絶の門、あるいは“動かない”という救い」

(舞台:青い城の城門。門には一語だけ刻まれている――DENY

デナイの門番止まれ。この城に“公衆の口”を開ける資源は入れぬ。この城に“鍵を裸で持つ者”は入れぬ。この城に“所在不明のログ”を持つ者は入れぬ。

(遠くで、デプロイの太鼓。CI/CDの兵が走り込み、旗を掲げる。旗には「急げ、今月中だ」とある。)

水無月(依頼人)通してくれ! 今日中に動けば、売上が立つんだ!

デナイの門番売上は門の理由にならぬ。門は、規範のためにある。

(門の前で立ち尽くすのは、現場の者――春野。背にはデプロイの失敗ログ。)

春野……また弾かれました。「ポリシー違反」って、あの冷たい文字。誰に、どう頼めば、この門を通れるんですか。

(影から笑い声。メフィスト。)

メフィスト頼む? 許可? 承認?そんなものは迂回すればいい。管理者権限を持つ誰かに頼め。一回だけ……こっそり、ポータルで、手で触ればいい。

ゲーテ(静かに)“こっそり”は、必ず後で牙を剥く。例外が必要なら、例外を制度にせよ。そして制度は、記録を伴わねばならない。

(山崎、桐谷、黒江が揃う。三者は門の前で頷き合う。)

黒江門を壊さずに通る道――それが「例外申請」です。でも紙の申請は遅い。クラウドの速度に、紙は追いつけない。

桐谷ならば“申請”も“承認”も“証跡”も、クラウドの中で完結させる。

山崎先生、ここからが第二部ですね。――例外申請の迷宮。

(幕)

第一場 「迷宮の入口――ロジカ、糸を垂れる」

(舞台:白い回廊。床に細い糸が走っている。糸の名は“ワークフロー”。奥で歯車の音。)

ロジカ(機械のように優雅)申請は入口を要する。入口は、整形された言葉を要する。言葉は、迷宮を迷わせない形を要する。

春野あなたが……ロジカ?

ロジカ私は“待つ”。私は“分岐する”。私は“証跡を残す”。人が眠る間も、私は糸を握り続ける。

黒江入口はHTTPの受け口にしましょう。フォームでも、パイプラインでも、ここへ投げる。投げる中身は固定化する――(彼女は羊皮紙に項目を書き出す)

  • 対象スコープ(どこに例外を付けるか)

  • 対象の policyAssignmentId(どの割り当てから免除するか)

  • (イニシアチブなら)policyDefinitionReferenceIds(束の中のどれを免除するか)

  • exemptionCategory(WaiverかMitigatedか)

  • expiresOn(いつまでか)

  • 申請理由、代替策、補償策

  • チケット番号(後追いの紐づけ)

ゲーテ“何を免除するか”より、“なぜ免除するか”が後で魂を救う。理由が曖昧な例外ほど、永遠に残るからだ。

メフィスト(軽く口笛)永遠に残る?なら最初から“期限”など書くな。今を救え。未来は未来の君が救えばいい。

ロジカ砂時計を忘れる者は、迷宮で干からびる。

(奥から砂が落ちる音。砂時計が現れる。)

第二場 「免除の札――“Waiver”と“Mitigated”の二つの顔」

(舞台:二つの札所。片方は赤い印――Waiver。もう片方は青い印――Mitigated。)

免除(エグゼンプト)の札係免除には二つの顔がある。Mitigated:意図は別の方法で満たした。Waiver:不適合を一時的に受け入れる。――好きな顔を選べ。だが、理由とセットだ。

桐谷ここが監査の要点です。“Mitigated”と言うなら、代替統制の証拠を添える。“Waiver”と言うなら、期限と是正計画を添える。(彼はゲーテを見る)先生、言葉が現実を縛りますね。

ゲーテ言葉は鎖である。鎖がなければ、人は便利の名で落ちる。

黒江免除には期限――expiresOnが付けられる。形式はUTCのISO 8601。期限が来ても“札そのもの”は残り、ただ効力が消える。記録のために残るんです。

(砂時計が落ちる音が一段大きくなる。)

※この場の設定は、Azure Policy Exemptions の概念(カテゴリ・期限・期限後の扱い)に基づく。

第三場 「選別の魔法――Resource Selectors、部分的な赦し」

(舞台:同じ免除でも、光が当たる範囲が違う。スポットライトが“場所”や“種類”で揺れる。)

春野でも……全部を免除するのは怖い。“その一部だけ”って、できないんですか?

免除の札係できる。resourceSelectors――場所(resourceLocation)や型(resourceType)などで、免除の効きを“部分”に切り分けられる。慎重な者は、全面赦しより、局所の赦しを好む。

黒江例えば“あるリージョンだけ暫定で免除”とか。移行期間だけ、限定的に。その方が統治としては綺麗です。

(メフィストが、札の束を振って笑う。)

メフィスト綺麗?綺麗は遅い。全部免除してしまえ。光なんて当てるな。

ゲーテ光を当てずに進む者は、いつか光の前で立ち尽くす。

※resourceSelectors の考え方(段階的な適用・ロールアウト/ロールバックの用途)は、公式の免除構造の説明に基づく。

第四場 「範囲外の誘惑――assignmentScopeValidation とメフィストの囁き」

(舞台:地図。管理グループ、サブスクリプションが駒のように動く。)

黒江原則、免除は割り当てスコープの中で作る。でも、例外的に――(彼女は声を落とす)サブスクリプションを別の管理グループへ移すとき、移動先のポリシーに引っかかって“移せない”ことがある。

メフィスト(待っていましたとばかりに)ならば、範囲外で作ればいい。検証など抜け。“DoNotValidate”と書け。門は開く。

桐谷……それは劇薬です。用途が限定されている。“範囲外免除”は、運用者の甘えのためではなく、移行を詰まらせないための技だ。

免除の札係assignmentScopeValidation。値は Default と DoNotValidate。DoNotValidateは、スコープ検証を迂回する――だが“本当に必要な時”だけだ。

ゲーテ影よ、聞け。迂回は技術であっても、倫理ではない。倫理がなければ、技術は契約にならない。

※assignmentScopeValidation(プレビュー)と想定用途(管理グループ間移動など)、許容値の説明は公式の免除構造の説明に基づく。

第五場 「承認の部屋――Teams の札、そして“待つ”という動作」

(舞台:青い鳥が飛ぶ。Teamsの使者。手に“カード”を持つ。)

チームズの使者承認は紙ではなく、カードで来る。押すのは判子ではなく、ボタンだ。

ロジカ私はカードを投げ、そして待つ。誰かが答えるまで、糸は止まる。止まることは失敗ではない。止まることは、合意のための空白だ。

(使者がカードを掲げる。カードには、こう書かれている。)

  • 申請者:春野

  • 例外対象:StorageAcc1(仮)

  • 免除対象:特定ポリシー割り当て(policyAssignmentId)

  • カテゴリ:Waiver(暫定受容)

  • 期限:30日(expiresOn)

  • 理由:業務要件(暫定)

  • 代替策:監視強化、アクセス制限、期限内に是正

  • 承認:✅Approve / ❌Reject

山崎(カードを見て)これなら、承認の判断材料が揃う。“理由”と“期限”と“代替策”。そして、後で追える“番号”。

桐谷Teams側のアクションで「カードを投稿し、応答を待つ」――ワークフローを停止させ、誰かが反応するまで継続させられる。

(ロジカが頷き、糸が張り詰める。)

※Teams コネクタに「Post adaptive card and wait for a response(カードを投稿して応答を待つ)」があり、応答があるまでフローが停止する、という性質に基づく。

第六場 「権限の門――マネージドID、そして“札を発行できる者”」

(舞台:再び門。今度は“権限”の門。上には刻印――Microsoft.Authorization/policyExemptions)

ロジカ承認が下りた。では私は、免除の札を発行しに行く。だが私は、人間のパスワードを持たない。持ってはならない。

ヴォルトの番人(どこからともなく)持つな。鍵は持つな。身分で開け。

黒江ロジカにはマネージドIDを持たせましょう。資格情報を埋めずに、Entraで守られた先へアクセスできる。ただし、対象リソース側で必要なロール付与が要る。(彼女は“付与”という言葉を重く発音する。)

権限の門番免除の札を扱うには、相応の権限が要る。読み書きできるだけでは足りぬ。免除は強い。強いゆえに、追加の条件がある。

桐谷免除オブジェクト管理には、例えば Resource Policy Contributor や Security Admin が関与し得る。そして免除を作る者は、対象割り当てに対しても特別な動作権限が要る――ここが“抜け”になりやすい。(彼は山崎を見る)規程に“誰が免除を発行できるか”を明記しましょう。

山崎二名承認、期限必須、理由必須、台帳記録。そして、発行権限は限定。例外が“裏口”にならないように。

※Logic Apps がマネージドIDで認証し、資格情報を持たずにEntra保護リソースへアクセスできる点、および対象側でロール付与が必要な点は公式説明に基づく。※Policy Exemption は追加の権限要件があり、関連する組み込みロールや必要操作(policyExemptions/write 等)がある点は公式説明に基づく。

第七場 「発行――ARMの回廊、PUTの一閃」

(舞台:長い回廊。壁に“management.azure.com”の文字。ロジカが糸を引きながら歩く。)

ロジカ発行は“更新”でもある。同じ名なら上書きし、違う名なら新設する。私はスコープと名で、札を置く場所を決める。

免除の札係(巻物を読み上げる)道はこうだ――

  • {scope}/providers/Microsoft.Authorization/policyExemptions/{name}

  • そこで札は生まれる。

  • その札は、スコープに含まれる資源すべてへ効く。

ゲーテ(小さく)“すべてへ効く”。だからこそ、スコープ設計は法務の領土だ。

ロジカ札の中身――propertiesには、最低限がある。

  • exemptionCategory(Waiver/Mitigated)

  • policyAssignmentIdそして必要なら、policyDefinitionReferenceIds や resourceSelectors、expiresOn、metadata。

(ロジカは札に、こう記す。metadata欄に、誰が申請し誰が承認したかを刻む。)

※Policy Exemptions の作成/更新が PUT で行えること、スコープ指定、必須プロパティ(exemptionCategory、policyAssignmentId など)、resourceSelectors 等の項目はREST仕様に基づく。※免除がスコープ配下の資源へ適用される性質(例:リソースグループスコープでの免除はRG内に効く)はREST仕様の説明に基づく。

第八場 「効力――“非準拠”から“免除”へ、そして見直しの輪」

(舞台:鏡の間。ディフェンダーとログの書記がいる。鏡の表示が“Non-compliant”から変わる。)

ディフェンダー免除は、無かったことにはならぬ。追跡の対象であり続ける。ただし評価は“免除”として扱われる。

ログの書記私は残す。申請、承認、発行、期限。そして期限が過ぎれば――札は残るが、効力は消える。記録のために残る。

春野(安堵しながらも)通れた……でも、これで終わりじゃない。

ゲーテ終わりではない。始まりだ。例外は“返す”前提で借りるもの。返す日を、最初から砂時計に刻め。

※免除が「追跡の対象でありつつ、評価上“exempt”として表示され得る」旨の説明と、expiresOn到来後もオブジェクトは残るが免除が尊重されない点は公式説明に基づく。

終幕 「メフィストの敗北――“裏口”を“正門の手続き”に変える」

(舞台:門の前。DENYはまだそこにある。しかし今は、横に小さな扉がある――“例外申請”。)

メフィスト面倒なことを……。だが認めよう。裏口を閉じたのは、私にとって不愉快だ。

ゲーテ裏口を閉じたのではない。裏口を“正門の手続き”に変えたのだ。――それが統治だ。

山崎先生、これで“クラウド法務”が一つ、形になりました。例外は、例外として残し、期限で返し、記録で追う。

ロジカ(糸を巻き取りながら)私は今日も待つ。誰かの承認を。誰かの責任を。そして、期限の鐘を鳴らす日を。

(砂時計の音。幕。)

舞台裏メモ(本作の“迷宮”を現実に落とすなら)

物語で描いた仕掛けを、現実の設計要素に翻訳すると次の通りです(要点だけ)。

  1. 例外は「Policy Exemption」で表現

  2. カテゴリは Waiver / Mitigated、期限は expiresOn(UTC ISO 8601)。期限を過ぎてもオブジェクト自体は残るが、免除は尊重されない。

  3. 限定的な免除(段階適用)

  4. resourceSelectors で場所・型などを条件に“免除の効く範囲”を狭められる。

  5. 特殊用途の“範囲外免除”

  6. assignmentScopeValidation: DoNotValidate は、スコープ検証を迂回し得る(主用途は管理グループ移動の阻害回避など、限定シナリオ)。

  7. 承認UI(Teams)で“待つ”を作れる

  8. Teams コネクタに「カード投稿→応答待ち」があり、応答までフローを停止できる。

  9. Logic Appsの認証はマネージドIDで(秘密を持たない)

  10. Logic AppsはマネージドID(システム割り当て/ユーザー割り当て)を使って、資格情報を持たずにEntra保護リソースへアクセスできる(ただし対象側で必要ロール付与が必要)。

  11. Exemption発行はARM REST APIで実施できる

  12. PUTで作成/更新でき、スコープ配下の資源に適用される。必須プロパティも明確。

  13. 免除管理には追加の権限要件があるので、発行権限者を限定し、承認と台帳をセットにする。

 
 
 

最新記事

すべて表示
“規程だけ”で終わらせないクラウド法務:Purview×ログ×権限でAIリスクを管理する方法

1. AIが進まない原因は「AI」ではなく「組織とルール」 生成AIの導入で企業がつまずく典型は、技術の難しさ以上に 「社内がたこつぼ化している」  ことです。 部門ごとに別々の生成AI・別々のルール データ共有や権限設計が追いつかず、使える人だけが使う リスク評価が属人化し、最後は「禁止事項の羅列」になって現場が萎縮 結果として「使わないのが安全」が組織の最適解になってしまう AIは“導入”では

 
 
 
【公取委の立入検査報道で再注目】クラウド移行の前に“Microsoftライセンス”と“出口条項”を棚卸しする理由

※本稿は一般情報です。個別案件の適法性判断・紛争対応は弁護士にご相談ください。 ■ 1. 何が起きているのか(ニュースの要点) 公正取引委員会が日本マイクロソフトに立入検査に入ったと報じられました。 報道では「Azureと競合する他社クラウドではMicrosoftソフトを使えない/料金を高くする等の条件を設けた疑い」が論点とされています。 結論はこれからですが、企業側として重要なのは―― “クラウ

 
 
 

コメント


Instagram​​

Microsoft、Azure、Microsoft 365、Entra は米国 Microsoft Corporation の商標または登録商標です。
本ページは一般的な情報提供を目的とし、個別案件は状況に応じて整理手順が異なります。

※本ページに登場するイラストはイメージです。
Microsoft および Azure 公式キャラクターではありません。

Microsoft, Azure, and Microsoft 365 are trademarks of Microsoft Corporation.
We are an independent service provider.

​所在地:静岡市

©2024 山崎行政書士事務所。Wix.com で作成されました。

bottom of page