ハイテク・製造・防衛・医療など、高セキュリティを求められる企業では、
「外部ユーザ(extドメイン) × SSO運用」 がほぼ定番になっています。
これは単に便利だからではなく、最大の理由は情報流出を防ぐための“境界管理”にあります。
🔧 構成イメージ
ユーザ種別 | ドメイン例 | 管理方法 | 主なセキュリティ施策 |
社内ユーザ | @company.com | Azure AD / Okta等 | SSO / MFA / SCIM |
外部ユーザ | @ext.company.com | 別のIDPまたは 同じIdPで別ドメイン運用 | SSO / MFA / SCIM / IP制限など |
ここで外部ユーザとは、協力会社や派遣社員等もありますが、顧客を含むことがあります。
超機密事項を含むやりとりでは、顧客側も extドメインを発行し情報を共有します。
ポイントは、同じIdPの中で“社内と外部”を明確に分けられること。
Atlassian Guard(旧Access)で ext ドメインを Verified Domain として登録すれば、SSOやMFA、IP制限も漏れなく適用できます。
🔒 情報流出対策として有効な理由
1️⃣ アカウント属性で境界を分離できる
extユーザは「社外」の扱いが一目でわかるため、
閲覧範囲や権限を細かく制御できます。
2️⃣ 契約終了後のアクセスを自動で遮断
SCIM連携により、IdPで無効化すればAtlassian側も即時反映。
“幽霊アカウント”による漏洩リスクを排除します。
3️⃣ ログが“外部用”として明確に残る
GuardやSIEMとの連携で、外部ユーザの操作記録を分離して管理。
監査・コンプライアンス対応がシンプルになります。
4️⃣ ダウンロードやAPI利用なども制限可能
外部ユーザには厳しめのポリシーを適用し、
データ持ち出しリスクを最小化できます。
4️⃣ 意外に重要:通知を外に出さない
外部ユーザには通知をexドメインのメールに通知し、顧客や協力会社へのドメインへ通知は行いません。
実例(簡易版)
A社(半導体):委託先とAtlassian Jiraで進捗共有
→ extドメインで分離し、プロジェクト単位でアクセス管理B社(医療機器):認証機関へAtlassian Confluenceの一部を開放
→ 閲覧専用+IP制限付きで最小権限アクセスC社(防衛):契約業者との仕様レビュー
→ Atlassian Guard+SCIMで外部ユーザ管理を完全自動化
まとめ
外部ユーザを「extドメイン+SSO」で管理することは、
ハイテク企業ではすでに標準的なセキュリティ運用です。
extドメイン運用で内部と外部を分離
IdP管理のSSO/MFA/SCIMで統制
Guardによるセキュリティポリシーとログ管理
ライフサイクルを自動化し漏洩リスクを最小化
これにより、利便性 × 統制 × ガバナンスを両立したゼロトラスト環境が実現できます。