同一テナント内で本番と切り離したDevサンドボックスを作るときは、ただサブスクリプションを分けるだけでは不十分です。ネットワーク経路、ID、秘密情報、ガードレールを最小コストで整えると、隔離と他サブスクリプション連携を両立できます。
Devサンドボックス環境で最初に決めるべき「分離の軸」
「サンドボックス」と聞くと、検証用リソースを気軽に作れる場所というイメージが先行しがちです。しかし、同一テナント内であっても本番と運用者を共有している以上、誤操作・誤設定・資格情報漏えい・横展開といったリスクは現実的に発生します。そこで最初に、何を何から分離するのか（分離の軸）を明確にします。
| 分離の軸 | 狙い | 具体例（サンドボックスでやること） |
|---|---|---|
| 課金・権限（管理プレーン） | 本番の予算・権限の巻き込みを防ぐ | サブスクリプション分離、管理グループ配下でAzure Policyを適用、PIMで特権ロールを時間制限 |
| ネットワーク（データプレーン含む） | 本番ネットワークへの到達性を最小化し、外部露出を防ぐ | パブリックIP禁止、Bastionのみで管理接続、Private Endpoint＋Private DNS、Outboundを制御 |
| ID・認証（人とアプリ） | 共有アカウント・静的秘密情報を排除 | 運用者はEntra ID＋MFA、アプリはManaged Identity、App登録は必要最小限 |
| 秘密情報・データ | 漏えい時の影響範囲を縮小 | Key VaultをPrivate Endpoint化、最小権限RBAC、ソフトデリート・削除保護 |
| 可観測性・監査 | 「起きたこと」を後から追える状態にする | Log Analyticsに診断ログ集約、NSGフローログ、Firewallログ、Activityログ、必要ならSentinel |
この5軸を押さえると、サンドボックスが「ただの検証環境」ではなく、安全に試せる実験場になります。以降は、VMでアプリを動かす前提で、分離と利便性の両立を具体的に詰めていきます。
サブスクリプション分離は「最初の一手」だが、これだけでは足りない
同一テナント内の別サブスクリプションにサンドボックスを作るのはベストプラクティスに沿った選択です。課金を切り分けられ、権限もスコープで限定しやすくなります。ただし、サブスクリプションを分けただけでは、ネットワーク到達性やIDの使い回しが残り、事故の温床になりがちです。
- 管理グループ：Sandbox用管理グループを用意し、サンドボックス用サブスクリプションを配下に置く（統制を一括適用しやすい）
- RBAC：Ownerは最小化し、運用はContributor/Readerなど必要最小限に分解する
- PIM：特権ロールは常時付与しない（時間制限・承認・MFAで昇格）
- コスト統制：サンドボックス用の予算（Budget）とアラートを設定し、想定外の高額化を早期に検知する
「本番の保護」を目的にするなら、サンドボックス側にガードレールを敷くのがコツです。本番側に過剰なDeny割り当てを増やすより、サンドボックスを“安全にしか作れない場所”にする方が運用が楽になります。
ネットワーク構成：Hub-Spokeと単独VNet、どちらが正解か
サンドボックスのネットワークは、理想はHub-Spoke、最小は単独VNetです。重要なのは「何を共有し、何を共有しないか」です。Hubを作る理由は、出口制御（Firewall）、DNS、共通監視、共通Private DNSなどを集約して運用を楽にするためです。一方で、サンドボックスが小規模で短命なら、Hubを持たない方がシンプルです。
| 構成 | 向いているケース | メリット | 注意点 |
|---|---|---|---|
| Hub-Spoke | サンドボックスが複数、または長期運用する | 出口制御やDNSを集約、ログとポリシーを横断で統一しやすい | 設計が重くなりやすい。Spoke間到達性を許しすぎないようにルート・NSGを整理する |
| 単独VNet（完結型） | 小規模・短命・まずは最小で始めたい | 構築が速い。責任範囲が明確。誤って他VNetへつなぐリスクが小さい | 出口制御やDNSが環境ごとに増える。後からHubへ寄せるときに手戻りが出やすい |
Hubを共有する場合でも、サンドボックスは「本番Hub」と同居させない判断が有効です。サンドボックスは実験が多く、ルートやDNSの変更が起きやすいため、本番用Hubとは論理的にも運用的にも切り分けたHub（または共有範囲を限定したHub）に寄せると事故が減ります。
推奨サブネット設計（VMベースのサンドボックス）
| サブネット名 | 用途 | ポイント |
|---|---|---|
| AzureBastionSubnet | Azure Bastion用 | 専用サブネット。ここ以外からのRDP/SSHを許可しないルール設計にする |
| WorkloadSubnet | VM/VMSSなどワークロード用 | NSGは許可リスト方式。必要ならASGで役割ごとにルールを整理 |
| PrivateEndpointSubnet | Private Endpoint用 | Network Policyの扱いに注意（設計方針を先に決める）。Private DNSとセットで考える |
| （任意）EgressSubnet | NAT Gateway/Firewall/NVA経由の出口用 | Outboundを固定し、外向き許可を明確化。監査ログを取りたいならFirewall寄せ |
パブリックIPは「作れない」ようにする
サンドボックスでよくある事故は、短期検証のつもりでVMにパブリックIPを付け、RDP/SSHを開けっぱなしにしてしまうことです。結果として、ブルートフォースや脆弱性スキャンの対象になり、テナント全体のリスクになります。推奨はシンプルで、VM/NIC/LB/Key Vault/Storageなど、あらゆるリソースでパブリック到達性を禁止します。
- 運用ルール：パブリックIPは例外申請がない限り使用不可
- 技術ガードレール：Azure Policyで「作成自体」を拒否（Deny）
- 例外設計：どうしても必要な場合は、専用の検証サブスクリプション／短期リソースグループに限定し、期限タグと自動削除をセットにする
「JIT（Just-In-Time）でRDP/SSHを開ければ安全」と考えがちですが、パブリックIPを残す時点で攻撃面は残ります。サンドボックスの原則としては、インターネットからのRDP/SSHはゼロに寄せるのが現実的です。
VMへの接続はAzure Bastionに一本化する
管理者のRDP/SSHはAzure Bastion経由に統一します。これにより、VM側にパブリックIPが不要になり、NSGのInboundルールも簡潔になります。加えて、条件付きアクセス（MFA、場所、デバイス準拠など）と組み合わせることで、運用者の入口も強化できます。
| 要件 | 推奨 | 補足 |
|---|---|---|
| ブラウザからのRDP/SSHで十分 | Bastionを利用 | 最小構成で始めやすい。まずは「入口の統一」が最優先 |
| 運用機能（同時接続、監査、利便性）を強化したい | Bastionの上位SKU/機能を検討 | 要件が固まってから段階的に拡張する。最初から盛りすぎない |
PaaSはPrivate Endpoint＋Private DNSで「閉じたまま使う」
Key VaultやStorage、Azure SQLなどのPaaSは、サンドボックスでも安易にパブリック公開しないのが基本です。Private Endpointを使うと、VNet内のプライベートIPでPaaSに接続でき、外部露出を大幅に減らせます。ここでつまずきやすいのがDNSです。Private Endpointを作っても、名前解決がパブリックを向いていると、意図せずパブリック側へ接続しようとして失敗したり、逆に公開してしまったりします。
- Private Endpoint作成
- 対応するPrivate DNSゾーン（Key Vault用、Storage用など）を作成または既存利用
- DNSゾーンをVNetにリンク（Hub-Spokeならリンク先の整理が重要）
- アプリ側の接続先は「いつも通りのFQDN」にして、DNSでプライベートへ解決させる
サンドボックスをシンプルに保つなら、Private DNSゾーンは「サンドボックス専用」に切り出すのが事故を減らすコツです。共通ゾーンに混ぜると、検証用に作ったEndpointのAレコードが他環境の挙動に影響する可能性があります。
NSG設計：許可リスト方式で、InboundもOutboundも最小化
NSG（Network Security Group）は、サンドボックスのネットワーク分離を「現実の安全」に落とし込む重要パーツです。ポイントは、サブネット単位で適用し、許可リスト方式でルールを組むことです。特にOutboundは放置されがちですが、検証環境ほど外部に自由に出られると、マルウェア混入や誤送信の影響が大きくなります。
代表的なNSGルール例
| 方向 | 優先度のイメージ | 許可 | 送信元 → 宛先 | 目的 |
|---|---|---|---|---|
| Inbound | 高 | RDP/SSH | AzureBastionSubnet → WorkloadSubnet | 管理接続をBastion経由に限定 |
| Inbound | 中 | 必要なアプリ間通信 | WorkloadSubnet内（ASGで限定） | 検証に必要な最小通信のみ |
| Inbound | 低 | 拒否 | Any → Any | デフォルト拒否で穴を塞ぐ |
| Outbound | 高 | Private Endpoint宛 | WorkloadSubnet → PrivateEndpointSubnet | PaaSへプライベート接続 |
| Outbound | 中 | 必要な外向き通信 | WorkloadSubnet → 目的の宛先（NAT/Firewall経由） | 更新、パッケージ取得など |
| Outbound | 低 | 拒否 | Any → Internet | 不用意な外部送信を抑止 |
Outboundを「全部拒否」に寄せると運用が破綻しやすいので、最初は出口を固定してログを取るところから始めるのがおすすめです。許可宛先の厳密化は、必要性が見えてから段階的に進められます。
Outbound戦略：NAT Gatewayか、Azure Firewallか
サンドボックスで悩みやすいのがOutbound（外向き）です。結論は、目的で選びます。「インターネットへ出られればよい」ならNAT Gatewayで出口IPを固定し、「何に出たかを制御・監査したい」ならAzure Firewall（またはNVA）を経由させます。
| 選択肢 | 向いているケース | 強み | 気を付ける点 |
|---|---|---|---|
| NAT Gateway | 小規模・低コストで、出口IP固定が目的 | 構成がシンプル。運用負荷が低い | きめ細かいURL/FQDN制御や脅威インテリジェンスの適用は弱い。ログは別途設計が必要 |
| Azure Firewall / NVA | Outbound制御、ログ取得、ドメイン単位制御をしたい | 許可リスト運用がしやすい。ログをLog Analyticsへ集約しやすい | コストと設計が増える。UDR（ユーザー定義ルート）と例外経路の設計が重要 |
「まずは最小で始めたい」場合は、NSG＋NAT Gateway＋Bastionが現実的なスタートラインです。次に必要になるのは、組織のポリシー（外部送信の監査要件）に応じたFirewall導入です。
DDoS対策：パブリックがないなら過剰投資しない
サンドボックスがパブリックエンドポイントを持たない設計なら、DDoS対策は「基本（標準）」で十分なことが多いです。逆に、将来どうしてもパブリック公開が必要なら、その時点で公開対象を限定し、WAFやDDoSの追加保護を含めて設計をやり直す方が安全です。サンドボックスでよくある失敗は、検証のための一時公開が恒久化してしまうことです。
Entra ID（旧Azure AD）設計：人のログインとアプリのIDを分ける
サンドボックスでも、ID設計は本番と同じ発想が必要です。重要なのは「人がログインするID」と「アプリがアクセスするID」を混ぜないこと。人はMFAや条件付きアクセスで守り、アプリはManaged Identityで秘密情報なしに動かします。
運用者のVMログインを安全にする
- Windows VM：Entra IDログイン（Azure ADログオン）を採用し、共有ローカル管理者パスワード運用を避ける
- Linux VM：証明書ベースのSSHログインやEntra連携ログインを使い、パスワード認証は無効化する
- 条件付きアクセス：MFA必須、特定のネットワーク/デバイス条件、リスクベース制御を組み合わせる
- 緊急用アカウント：例外はゼロにできないため、ブレークグラス（非常用）を定義し、保管・監査・ローテーションを徹底する
アプリコードのIDはManaged Identityが基本
VM上で動くアプリがKey Vault/Storage/Service Bus/Azure SQLなどにアクセスするなら、Managed Identity（マネージドID）が第一選択です。シークレットを配布・更新する運用が不要になり、漏えいリスクと運用コストが同時に下がります。
| 選択 | 使いどころ | メリット | 注意点 |
|---|---|---|---|
| システム割り当てManaged Identity | VMごとに固有のIDで良い | 設定が簡単。VM削除と同時にIDも消えるので棚卸しが楽 | 複数VMで同一IDを使いたい場合は不向き |
| ユーザー割り当てManaged Identity | 複数VM/VMSSで同一IDを使い回したい | IDをリソースとして管理できる。移行やスケールに強い | IDのライフサイクル管理が必要（不要になったら削除・権限剥奪） |
アプリからのトークン取得は、VM上のメタデータサービス（IMDS）経由で行い、クレデンシャルをファイルや環境変数に置かないのが基本です。ローカルに秘密情報が存在しない構成は、サンドボックスの「雑さ」を許容しつつも安全性を担保します。
クロスサブスクリプションアクセスは「RBACの付け先」がすべて
同一テナント内であれば、Managed Identityが他サブスクリプションのリソースへアクセスすること自体は特別な仕組みを必要としません。ポイントは、対象リソース側（アクセスされる側）にRBACを付与すること、そして管理プレーンとデータプレーンのロールを混同しないことです。
| アクセス先 | よく使うロール例 | スコープのコツ |
|---|---|---|
| Key Vault（シークレット読み取り） | Key Vault Secrets User | まずはVault単位。複数Vaultに広げる前に必要性を確認 |
| Storage（Blobの読み取り/書き込み） | Storage Blob Data Reader / Storage Blob Data Contributor | ストレージアカウント全体より、コンテナー単位の分離も検討 |
| Service Bus / Event Hubs | Data Sender / Data Receiver系のロール | Namespace単位で権限を閉じる。検証用エンティティに限定する |
| Azure SQL | （SQL側のEntra管理者設定＋DB内権限） | Azure RBACだけで完結しない場合がある。DBロール設計もセットで |
「とりあえずContributorを付ける」は短期的には楽ですが、サンドボックスが長期化すると必ず負債になります。読み取り・書き込み・管理操作を分け、スコープもリソースグループやリソース単位で狭めるのが、後から効いてきます。
App登録（アプリ登録）を使うべき場面を限定する
App登録（クライアントID＋シークレット/証明書）を使うと、アプリはどこでも認証できますが、その分シークレット運用が必ず発生します。サンドボックスの運用コストを上げないためにも、Managed Identityで足りる限りはManaged Identityが原則です。
| 要件 | 推奨 | 理由 |
|---|---|---|
| Azureサービス（Key Vault/Storage/Service Busなど）へアクセス | Managed Identity | 秘密情報不要で最小運用。RBACで最小権限にしやすい |
| 自作APIをEntraで保護し、クライアントとして呼び出す | ケースによりApp登録 | APIのスコープ設計や認可モデル次第で、明示的なアプリIDが必要になる |
| Microsoft Graphで委任権限が必要（ユーザー代行） | App登録＋委任フロー | ユーザー文脈が必要な処理はManaged Identityだけでは成立しない |
App登録が必要な場合でも、シークレットより証明書を優先し、格納はKey Vault、取り出しはManaged Identity経由にすることで、リスクを最小化できます。
秘密情報管理：Key Vaultを「必須コンポーネント」にする
サンドボックスであっても、接続文字列やAPIキーをVM内ファイルに置く運用は、いつか必ず漏えいの起点になります。Key Vaultを中核に据え、アプリはManaged IdentityでKey Vaultから必要なものだけ取得するのが安全です。
- ネットワーク：Key VaultはPrivate Endpointのみ、パブリックネットワークアクセスは無効
- 認可：RBAC（またはアクセスポリシー）で、VMのManaged Identityに必要最小権限を付与
- 保護：ソフトデリートと削除保護（パージ保護）を有効化し、誤削除に備える
- 運用：シークレットの有効期限・ローテーションを定義し、用途タグで棚卸しできるようにする
ディスク暗号化をカスタマー管理キー（CMK）で強化する場合も、キー保管先はKey Vault（またはManaged HSM）になります。サンドボックスの段階では必須でないことも多いですが、「本番へ寄せる」予定があるなら早めに設計のクセを合わせておくと移行が楽です。
VMの堅牢化とパッチ管理：サンドボックスほど“標準化”が効く
サンドボックスはスピード優先になりやすく、VMの初期設定が人によってバラつきがちです。だからこそ、ベースイメージと更新運用を標準化すると、セキュリティと運用効率が一気に上がります。
| 領域 | 最低限 | 推奨 | 余裕があれば |
|---|---|---|---|
| ベースイメージ | 公式イメージを使用 | セキュリティベースライン準拠のイメージ（CIS等） | 自社ゴールデンイメージ化（Packer等） |
| パッチ | 手動更新でも可（短命なら） | Azure Update Manager等で継続更新 | メンテナンスウィンドウ自動化、更新失敗時の復旧手順整備 |
| 脆弱性対策 | Defender for Cloudの基本推奨を確認 | 推奨事項を定期的に潰す運用 | 脆弱性管理の自動チケット化、例外管理 |
| 認証 | SSH/RDPをBastion経由 | Linuxはパスワード無効、Windowsはローカル管理者最小化 | 特権操作はPIM＋監査ログ、運用端末制限 |
サンドボックスは「壊して作り直す」ことが許される環境です。だからこそ、IaC（Bicep/Terraformなど）で再現可能にして、パッチや設定の手作業を減らすと、結果的に安全になります。
監視・ログ：最小でも「後追いできる」状態を作る
サンドボックスは本番より軽視されがちですが、事故が起きたときに原因究明できないと、同じ失敗を繰り返します。最初からすべてのログを集めようとするとコストが跳ねるため、まずは「最低限の監査ライン」を決めて集約します。
| ログ/テレメトリ | 主な用途 | まず集めたい理由 |
|---|---|---|
| Azureアクティビティログ | 誰が何を変更したか | 誤操作の追跡に必須。サブスクリプション単位で横断できる |
| VM診断ログ・ゲストOSログ | OS内のイベント | ログイン失敗、サービス異常などの分析に必要 |
| NSGフローログ | 通信の可視化 | 「どこへ通信しているか」を知るとOutbound制御が進めやすい |
| Firewallログ（導入時） | 外向きの許可/拒否 | 許可リスト運用の根拠が取れる。監査要件にも対応しやすい |
| Key Vault診断ログ | シークレット/キーの利用監査 | 漏えい時の影響範囲確認に直結する |
余裕があればMicrosoft Sentinelにオンボードし、サンドボックス向けに「軽めの検知」を入れると、学習効果が高まります。例えば、管理者ロールの急増、Key Vaultの大量取得、普段使わない国からの操作などは、サンドボックスでも早期に気づきたい典型です。
ガバナンス：Azure Policyで“作り方”を縛ると運用が楽になる
人の善意やルールだけでサンドボックスの安全を守るのは難しいので、Azure Policyでガードレールを敷きます。特に効果が高いのは、パブリックIP禁止、NSG必須、診断ログ必須、Private Endpoint必須、タグ必須です。
| ガードレール | ポリシー例（意図） | 得られる効果 |
|---|---|---|
| パブリックIP禁止 | NIC/VM/LBへのPublic IP作成を拒否 | 事故が起きる前に物理的に止める |
| NSG必須 | 全サブネットにNSGが関連付いていない場合は拒否/修復 | 「無防備なサブネット」をなくす |
| PaaSのPrivate Endpoint必須 | Key Vault/Storage/SQLなどのパブリックアクセスを拒否 | データプレーンの外部露出を防ぐ |
| 診断設定の自動適用 | DeployIfNotExistsでLog Analytics送信を自動設定 | ログ設定漏れを減らし、監査の最低ラインを保つ |
| タグ必須 | Owner/用途/期限/データ分類などのタグがなければ拒否 | 棚卸し・コスト管理・自動削除の土台になる |
コストとライフサイクルのガードレールも「セキュリティ」
サンドボックスは放置されやすく、使われていないVMやディスクが残り続けると、コストだけでなく攻撃面も増えます。期限管理と削除の自動化は、結果的にセキュリティを高めます。
| 施策 | やること | 効く理由 |
|---|---|---|
| 期限タグ（ExpiresOn） | 作成時に必須タグとして期限を入れる | 棚卸しと自動削除の起点になる。永続化を防げる |
| 自動停止/自動削除 | 夜間停止、期限到来で削除する仕組みを用意 | 未使用リソースが減り、攻撃面とコストが同時に減る |
| 許可SKU/許可リージョン | 高額SKUや不要リージョンをポリシーで制限 | 想定外コストと設計のばらつきを抑える |
| Budgetアラート | 月次上限と通知を設定 | コスト異常（暴走や不正作成）を早期発見しやすい |
ロックとDeny割り当ては「守る範囲」を絞って使う
運用を簡単にするため、共有基盤（例：ログ基盤、DNS基盤、共通ポリシーのリソースグループ）には削除ロックを付けるのが有効です。一方でDeny割り当ては強力なので、乱用すると運用が詰まります。サンドボックスでは、絶対に触ってほしくない範囲に限定し、例外手順も含めて運用ルール化しておくと安全です。
ポリシーは「最初から完璧」を目指さず、まずは事故が大きいもの（パブリックIP、ログなし、秘密情報の放置）から優先すると、反発も少なく定着しやすいです。
「シンプルなサンドボックス」でどこまでやるべきか
すべてを本番同等にすると、サンドボックスの価値（スピード）が失われます。一方で、最低限を外すと事故が増え、結局スピードが落ちます。おすすめは、成熟度で段階を分けるやり方です。
| レベル | 狙い | 必須コンポーネント | この段階では割り切ること |
|---|---|---|---|
| 最小（まず動く） | 安全に「試せる」状態を早く作る | サブスクリプション分離、Public IP禁止（ポリシー）、Bastion、NSG（最低限）、Key Vault（Private Endpoint）、Managed Identity | Outboundの細かなURL制御、Sentinel常時監視、CMKなどは後回し |
| 標準（運用できる） | 長期運用でも事故が起きにくい | NAT/Firewallで出口固定＋ログ、診断設定の自動適用、Update運用、PIM、期限タグ＋棚卸し | ゼロトラストを完璧に再現することより、ガードレールの徹底を優先 |
| 強化（統制・監査が必要） | 監査要件や組織標準に合わせる | Firewallで厳密な許可リスト、Sentinel、標準イメージ、例外管理、Deny割り当て（限定） | サンドボックスの自由度は下がる。用途と対象チームを明確にして導入 |
迷ったら、まずは「最小」＋「標準」までを狙い、チームの利用実態が見えてから強化へ進めるのが失敗しにくい流れです。
導入ステップ：迷わないための実装順
- サンドボックス専用サブスクリプションを作成し、Sandbox管理グループ配下に配置する
- VNetとサブネット（AzureBastionSubnet、WorkloadSubnet、PrivateEndpointSubnet）を作成する
- Azure Bastionをデプロイし、VMはパブリックIPなしで作成する
- 各VMにシステム割り当てManaged Identityを付与する
- Key Vaultを作成し、Private EndpointとPrivate DNSを構成、パブリックアクセスを無効化する
- VMのManaged Identityに、Key Vaultや必要なPaaSの最小権限ロールを付与する（必要なら他サブスクリプション側に付与）
- Defender for Cloudと診断設定を有効化し、Log Analyticsに集約する
- Azure PolicyでパブリックIP禁止、NSG必須、診断ログ必須、Private Endpoint必須、タグ必須を適用する
- Outbound用にNAT Gateway（最小）またはAzure Firewall（制御・監査重視）を構成する
- 運用者ログインをEntra ID＋MFAに寄せ、ローカルパスワード運用を縮小する
よくある落とし穴と回避策
Private Endpointを作ったのに接続できない（DNS問題）
- Private DNSゾーンがVNetにリンクされているかを確認する
- Hub-Spokeの場合、どのVNetが名前解決を担うか（Hub集約か、Spoke個別か）を決めておく
- 名前解決が複雑になったら、Private DNSの運用手順（レコード命名、削除、棚卸し）を先に作る
RBACを付けたのにアプリがアクセスできない（ロールの種類違い）
- 管理プレーン（Reader/Contributor）ではなく、データプレーン（Storage Blob Data Reader等）が必要なケースがある
- スコープが広すぎる・狭すぎると想定外の挙動になるため、まずはリソース単位で試して広げる
- 権限変更の反映には時間差があるため、トラブル時はトークンの再取得も考慮する
ログを集めすぎてコストが跳ねる
- 最初はアクティビティログ、Key Vault、Firewall/NSG、VMの基本ログなど「目的が明確なもの」に絞る
- 保持期間（Retention）を決め、短命サンドボックスは短めにする
- 検証が終わった環境は自動削除（期限タグ＋自動化）で“ログも含めて”整理する
まとめ：安全なサンドボックスは「禁止」ではなく「仕組み」で作る
Devサンドボックス環境のセキュリティは、利用者に我慢を強いるほど定着しません。サブスクリプション分離を起点に、パブリックIP禁止、Bastionで入口統一、Private EndpointでPaaSを閉域化、Managed Identityで秘密情報を消す。この骨格をAzure Policyで“作れない”形にすると、スピードと安全性が同時に手に入ります。必要に応じてFirewallやSentinelを足し算しながら、自社の検証スタイルに合ったサンドボックスを育てていきましょう。
コメント