Atlassian Cloud Enterpriseにおけるアクセス制御と監査ログ機能

Atlassian Cloud Enterprise（対象製品: Jira Software, Confluence, Bitbucket など）では、大規模組織向けに強化されたアクセス制御と監査ログの機能を提供しています。本レポートでは、ユーザー・グループの権限管理、シングルサインオン（SSO）、SCIMプロビジョニングといったアクセス制御機能、およびログ収集・検索・保持・エクスポートを含む監査ログ機能について、各機能の概要、製品ごとの対応状況、Enterpriseプラン固有の拡張、管理者設定オプション、エクスポートやAPI連携の可否を整理します。

Atlassian Cloudでは、ユーザーやグループ管理が各製品から分離され中央集権的に行われます。管理者は組織 (Organization) 単位で提供される管理サイト（admin.atlassian.com）から、組織配下の全ユーザーやグループを一元管理します。Enterpriseプランでは複数のサイト（インスタンス）を1つの組織に属させることが可能で、同一組織内の全サイトは共通のユーザーベース（管理アカウント）と設定を共有します。例えば一つの組織にJiraやConfluenceの複数インスタンスがあっても、ユーザーアカウントやグループは組織全体で統一的に管理されます。EnterpriseプランではAtlassian Access (Atlassian Guard Standard) がプランに含まれているため、組織レベルのユーザー管理機能を追加費用なしで利用できます。

アプリ（製品）へのアクセス権付与: Atlassian Cloudではユーザーに各製品へのアクセス権を与える仕組みとして「アプリアクセス (App access)」の概念があります。組織管理者 (Org admin) は管理サイト上で、ユーザーまたはグループに対しJiraやConfluenceといった各アプリへのアクセス権を付与します。この際、ユーザーにはそのアプリ内でのロール（通常は「ユーザー」または「管理者」）を割り当てることもできます。一度アプリアクセスが付与されると、該当ユーザーはその製品のライセンス利用者とみなされ課金対象となります。グループ単位で製品アクセスを付与することが一般的で、たとえば「jira-software-users」グループにユーザーを追加するとJira Softwareへのアクセス権を得ます。アクセス権を持たないユーザーも組織に存在できますが、ログインはできても製品の操作はできず、ライセンス数にはカウントされません。

製品内権限（パーミッション）の管理: 製品へのアクセス権付与は「その製品に入る権利」を与える第一段階の制御であり、実際の製品内での細かな操作権限は各アプリ固有の権限体系で管理されます。例えばJiraではプロジェクトロールや権限スキーム、Confluenceではスペース権限やページ閲覧制限といった仕組みがあり、これらは各アプリの管理画面上で管理者（サイト/製品管理者）によって設定します。これらの細粒度のパーミッション管理機能はCloud EnterpriseプランでもStandard/Premiumと基本的に同一であり、Enterpriseプラン固有の拡張はありません（ただしEnterpriseでは複数サイトを持てるため、組織管理者が各サイトのサイト管理者と協力して全体を統制します）。各製品のグローバル権限（全プロジェクトや全スペースに及ぶ管理権など）も同様にサイトごとに設定されます。組織管理者は各サイトのサイト管理者権限を持つことで全ユーザーやグループを横断的に管理でき、必要に応じてサイト管理者に昇格することも可能です。

Enterpriseプランならではのポイント: Enterpriseプランでは複数サイトでの一括ユーザー管理や共通ユーザーベースにより、大規模組織でのユーザーライフサイクル管理が容易になります。また、Enterpriseプラン契約時にAtlassian Access (Guard Standard)が包括されるため、SAML SSOやSCIMといった高度なアイデンティティ管理機能や組織全体のセキュリティポリシーを追加コストなしで適用できます。これにより、企業は全ユーザーに対し一律のセキュリティ統制（例えばログイン経路や認証要件）を課すことができ、組織やサイトをまたいだ統合ガバナンスを実現できます。

概要: Atlassian Access（Guard Standard）の主要機能として、SAML 2.0ベースのシングルサインオン (SSO) が提供されます。SSOを構成すると、ユーザーは自社のアイデンティティプロバイダー（IdP）を通じて認証し、一度ログインすればセッション中は複数のAtlassianクラウド製品に再ログインなしでアクセス可能になります。これにより社内認証ポリシーの統一（パスワード強度や多要素認証など）や、ユーザーの利便性向上が図れます。

対応製品: SSOは組織に紐づく管理対象アカウントすべてに適用され、Jira, Confluence, BitbucketなどすべてのAtlassian Cloudアプリに横断的に有効となります。SSOはAtlassianアカウント単位の認証方式であり、各アプリ個別に設定するものではありません。一度SSOを設定すると、対象ドメインのユーザーはAtlassianアプリへのログイン時にIdPによる認証が要求されます（※ドメイン未管理のアカウントは対象外）。Enterpriseプランでは組織運用上、複数のメールドメインにユーザーがまたがることもありますが、Atlassian Accessでは複数のIdPディレクトリを組織に接続し、ドメインごとに適切なIdPでSSO認証させることも可能です（例: @eu.example.comはAzure AD、@us.example.comはOktaに連携）。

Enterpriseプラン固有の利点: 前述の通りEnterprise契約にはAtlassian Accessが含まれているため、追加料金なしでSAML SSO機能を利用可能です。これにより組織全体でのSSO標準適用が容易になります。またSSO適用に際しては、Atlassian Accessの「認証ポリシー」により特定ユーザーグループのみSSO必須にするといった柔軟な運用も可能です。たとえば一部パイロットユーザーでSSO設定を試験し問題なければ全ユーザーに拡大する、といった運用ができます。Enterprise組織では万が一IdPに障害が発生した場合に備え、SSOを経由しない非常用管理者アカウントを用意しておくことも推奨されています（設定ミス時のロックアウト防止策）。

管理者設定オプション: SSOを利用するには、まず組織でドメインを検証しアカウントを「管理対象」にする必要があります。次にAtlassian Access側でIdP情報（エンティティIDやSAMLエンドポイント、証明書など）を設定し、IdP側でもAtlassian Cloud向けのSAML連携アプリを構成します。Atlassian側では管理者 (Org admin) 権限があれば、管理サイトの「シングルサインオン」設定画面から主要IdP（Okta, Azure AD, OneLogin, Google Workspace, ADFS等）向けのガイドに従い容易にセットアップできます。設定後、ユーザーがメールアドレス入力でログインを試みると自動的にIdPの認証ページにリダイレクトされます。なお、SSO適用後もAtlassianはアカウントごとにバックアップ用のパスワードログインを保持しますが、組織の認証ポリシーでSSO経由ログインを必須化すること（ID/パスワードでの直接ログインを禁止する設定）も可能です。

エクスポート/API連携: SSO設定自体に対するエクスポート機能は特にありませんが、IdPによってはメタデータXMLのインポート/エクスポートで設定可能です。SSOの状態（どのユーザーがいつ認証したかなど）は監査ログに記録されますので、後述の監査ログAPIやCSVエクスポートによりSSO関連イベントを取得できます。またAtlassian AccessではIdPとの接続ステータスや認証トラフィック自体を外部連携するAPIは提供していませんが、SSOの有効/無効切り替え等は管理者がGUI上で即時可能です。

概要: Atlassian AccessはSCIM 2.0 (System for Cross-domain Identity Management)に準拠したユーザープロビジョニング機能を提供し、外部のアイデンティティ管理システムとユーザー・グループ情報を同期できます。SCIMプロビジョニングを使用すると、組織のIdPやディレクトリでユーザーを作成・更新・削除した際に、その変更が自動的にAtlassian Cloud組織に反映されます。例えば新入社員をIdPで「対象アプリ=Jiraユーザー」として登録すると、自動的にAtlasiian側でもアカウントが作成され適切な製品アクセス権が付与されます。また退職者のアカウントをIdPで無効化すればAtlassian側でも自動で**無効化（デ deaktivated）**され、セキュリティ上のリスクを低減できます。

対応サービスと製品: Atlassian AccessのSCIM連携はOkta, Azure AD, OneLogin, Ping Identity, Google Cloudなど主要なクラウドIdPに対してネイティブにサポートされています。Atlassianが公式サポートしていないIdPであっても、Atlassianが公開するSCIM API（RESTベース）を利用してカスタム連携を実装可能です。プロビジョニング対象は組織管理下の全Atlassianアカウントであり、Jira Software, Confluence, Bitbucket等のクラウド製品で共通のアカウントが自動作成されます。注意点として、グループ同期機能については現時点でJira系アプリ・Confluence・Trelloではサポートされていますが、Bitbucket Cloudでは未対応です。つまりIdP上のグループを同期してJiraやConfluence側にグループを自動作成・更新することは可能ですが、Bitbucketのワークスペースグループには直接同期されません（Bitbucketユーザー自体はSCIMで自動追加・無効化可能です）。

Enterpriseプラン固有の利点: Enterpriseプラン（＋Atlassian Access）環境では、人事異動や組織変更による大規模ユーザー管理が発生しても、SCIMにより手動操作なしで即時反映されます。これにより大企業で問題となりがちな「ユーザーアカウントの棚卸し漏れ」や「不要アカウントの残存」を防ぎ、ライセンスコスト最適化やセキュリティ強化につなげられます。またEnterprise組織では複数のサイトにまたがって同一ユーザーが存在するため、SCIMを用いた集中管理により全サイトに対するユーザー一括オンボーディング/オフボーディングが実現します。Atlassian Access (Guard Standard)が含まれていることで、SCIM機能利用に追加費用は不要です。

管理者設定オプション: SCIMを利用するには、Atlassian組織にIdPディレクトリを登録し、SCIM API統合用の**APIトークン（APIキー）**を発行します。次にIdP側でAtlassian Cloud向けのプロビジョニングを有効化し、先ほどのAPIトークンと組織IDなどを設定します（例えばOktaではAtlassian Cloud用のSCIM統合設定画面があり、必要情報を入力して連携をオンにします）。管理サイトの「ユーザープロビジョニング」画面では、同期の状態（最終同期日時や成功/失敗件数）、属性マッピングの設定、グループ競合時の挙動設定などを管理できます。またIdPとの同期間隔はIdPに依存しますが、OktaやAzure ADでは概ね40分おきなど定期的にプロビジョニング実行されます。属性マッピングはデフォルトで氏名・メールアドレス・部署名など標準項目が対応しており、サポートされるカスタム属性についてはAtlassianのドキュメントに一覧があります。Bitbucket向けのグループ同期が不要な場合、同期エラーを避けるためAtlassian側でBitbucketアカウントの自動リンク設定（Workspaceと組織のリンク）を事前に行っておくことが推奨されています。

エクスポート/API連携: SCIM自体がAPI連携機能であるため、通常はIdP製品がSCIMクライアントとなってAtlassianのSCIMエンドポイントにAPI経由で変更を送信します。前述のようにAtlassianは独自のUser Provisioning APIを公開しており、これを使って社内システムから直接ユーザーやグループを管理することもできます。このAPIはSCIM 2.0標準に準拠しているため、柔軟な自動化が可能です。なお、ユーザーやグループの一覧をCSVエクスポートする機能も管理サイト上にあります（例えば「管理対象アカウント」をCSV出力することでユーザー情報を監査・バックアップできます）。

概要: Atlassian Accessの一部として、ユーザーのログインに関する認証ポリシーを組織単位で定義できます。主要なポリシー項目としてはパスワードポリシー（パスワードの最低文字数・複雑性要件など）、2段階認証 (Two-step verification) の強制、セッション管理（アイドルタイムアウトやモバイルアプリのセッション期限）などがあります。これらはSSOを使用しない場合でも適用可能で、Atlassian標準のクラウド認証を強化する目的で提供されています。たとえば組織のセキュリティ要件に合わせて「全ユーザーに対しAtlassianアカウントへの2段階認証を必須化する」ことができます。2段階認証を有効にすると、ユーザーは通常のパスワード入力後に加えて認証アプリやSMSによるコード入力が必要となり、不正ログインのリスクを低減できます。

対応範囲: 認証ポリシーは組織に属するすべてのクラウド製品に共通して適用されます。個別製品ごとにパスワードポリシーを分けるといったことはできず、組織の全Atlassianアカウント（または特定のポリシーに割り当てたユーザーグループ）に対して統一ルールが enforce されます。Enterpriseプランでは大多数のユーザーにSSO経由ログインさせるケースも多いですが、IdP側で多要素認証を運用していない場合、Atlassian側で2段階認証を必須にすることが有効です（SSO利用時でもバックアップログインとして有効になります）。Bitbucket単体利用ユーザーなどSSOを通らないケースでは、Atlassian側の2段階認証強制が特に重要です。

Enterpriseプラン固有の利点: Atlassian Access (Guard Standard)加入済みであれば、これら認証ポリシー機能も利用できます。Enterpriseでは大規模ユーザーに一括ポリシーを適用できるため、セキュリティ水準のばらつきを防げます。例えば以前は各ユーザー任意だった2段階認証を、Enterprise組織では管理者が強制的に有効化できるため、全ユーザーで統一された多要素認証が実現します。またパスワード変更ポリシー（有効期限や使い回し禁止など）はAtlassian標準では細かな設定がありませんが、IdP連携していない組織でもEnterprise+Accessで独自に強度要件を設けられます。

管理者設定オプション: 管理サイトの「セキュリティ > 認証ポリシー」画面から、デフォルトポリシーの編集や複数ポリシーの作成（特定ユーザーを除外する非課金ポリシー等含む）が可能です。そこでパスワード最小長や文字種要件を指定したり、「二段階認証を必須」オプションをオンにしたり、セッションタイムアウト時間を設定できます。設定を有効にすると対象ユーザーには次回ログイン時から適用され、不適合なパスワードのユーザーには変更が求められます。Bitbucketなど一部製品では独自に2FAを有効化する機能がありましたが（ユーザーごとに設定するオプション）、Atlassian Accessのポリシー適用時には組織全体で統一管理されます。ログインページのカスタマイズ（社ロゴやヘルプリンクの表示）も可能で、これによりユーザーに組織専用ログイン画面を提供できます。

エクスポート/API連携: 認証ポリシー設定そのものをエクスポートする機能はありませんが、設定内容はUI上で確認できます。またユーザーごとの2段階認証有無や最終ログインなどの情報は組織管理画面からCSVエクスポート可能です（「管理対象アカウント」のエクスポートに含まれる）。API経由で直接認証ポリシーを変更する機能は提供されていませんが、ユーザーの二段階認証状態を監視するためのAPI（ユーザーのセキュリティ情報取得API）は今後拡充が進められています。現在は監査ログにポリシー変更や2FA有効化イベントが記録されるため、後述の監査ログAPIを通じてポリシー遵守状況をモニタリングする運用が考えられます。

Atlassian Cloudでは、システム上の重要な操作履歴を記録する監査ログ (Audit Log) が提供されています。Enterpriseプランでは監査ログ機能が拡張され、組織全体から各製品レベルまで包括的にログを追跡できます。監査ログには主に以下の3種類のログ種別があります:

Enterpriseプランにおける提供内容: Cloud Enterpriseでは、組織管理ログおよび各アプリの管理ログ・ユーザーログすべてにアクセスできます。たとえばJiraとConfluenceの場合、Premiumプランでは各アプリの管理者操作のみが監査ログで確認できましたが、Enterpriseプランではユーザーによるコンテンツ操作も含めてログが記録・閲覧可能です。Bitbucket Cloudに関しては、単体プランとしてはStandard/Premiumの区別がないため、Atlassian Accessを通じて監査ログが提供されます。Bitbucketの監査ログはAtlassian Accessの組織監査ログに統合され、Workspaceでのユーザー操作（リポジトリ作成・削除、権限変更、分岐操作など）を組織管理者が確認できます。

なお、Atlassian Access (Guard Standard)契約時にはEnterpriseプランでなくても組織管理ログは利用できます。しかし各アプリのログは対応する製品プランに依存し、Premium/Enterpriseでないと取得範囲が制限されます。Enterpriseプランでは全サイトがPremium相当以上になるため、組織管理者は組織全体の一括監査ビューから各種ログを横断的に検索・分析できます。

ログ閲覧方法: 監査ログは管理者コンソールから閲覧できます。組織管理ログおよび各アプリのログは、統合されたインターフェース（admin.atlassian.comの「Security > Audit log」）上で一元的に表示されます。画面ではログを時系列で確認でき、イベントごとに「どのユーザーが」「いつ」「どの操作を」「どの対象に」行ったかの詳細が表示されます。管理者はキーワード検索や期間指定フィルターで必要なログエントリを絞り込むことが可能です。たとえば特定ユーザー名やIPアドレス、操作種類（例: "Group created" や "Page viewed"）でフィルターし、該当するイベントのみを一覧表示できます。各ログエントリは詳細ペインで追加情報（例えば操作によって変更された設定値や対象オブジェクトのIDなど）を表示でき、必要に応じ管理者がその内容を監査・追跡できます。

各アプリ個別にも、サイト管理者用の監査ログ画面が提供されています。例えばConfluenceでは管理者設定画面から「監査ログ」を開き、同様にフィルタ検索や詳細確認ができます。Jira Cloudもシステム管理内に監査ログ画面があり、フィルタリング機能は共通です。Enterpriseプランでは組織レベルで包括的に見る方法と、サイト単位で個別に見る方法の両方が可能です（裏では同じデータソースを参照）。Bitbucket CloudのログはAtlassian Access側に集約されるため、組織Audit Log画面で閲覧します。

保持期間とポリシー: Atlassian Cloudの監査ログ保持期間はプランによって異なります。組織監査ログ（Atlassian Access経由で集約されるログ）は**最大で6か月（180日）**分のイベントを保持します。これは2023年のポリシー変更により定められた期間で、業界標準やデータプライバシーに配慮した期間となっています。そのため、6か月を超える過去の組織ログは自動的に削除されるため、定期的なエクスポートが推奨されます。

一方、各アプリの監査ログについてはPremium/Enterprise環境では最大1年間の保持が可能です。例えばConfluence Cloudではデフォルトで12か月間イベントを保持し、管理者が設定画面で1～12ヶ月の範囲で保持期間を変更できます。Jira Cloudも同様に、ログ保持期間を1～12ヶ月で調整可能です（デフォルト12ヶ月）。保持期間に達したログは週次のクリーンアップ処理でローテーション削除されます。なお、Standardプランでは高度な監査ログ機能が限定されているため、保持期間もより短いかログ自体が限定的です（Jira/Confluence Standardでは一部重要イベントのみ6ヶ月保持等）。EnterpriseプランではPremium相当の監査ログ機能が有効となり、最長1年の保持が保証されます。

ユーザー生成コンテンツ情報の取り扱い: 監査ログの中には、ユーザー操作ログとしてページタイトルや課題キーなどコンテンツ固有の情報が含まれる場合があります。これらは場合によっては機密情報となり得るため、AtlassianはEnterpriseおよびGuard Premium環境向けに「ユーザー生成アクティビティの記録設定」を提供しています。組織管理者は管理サイトの監査ログ設定から、アプリごとにユーザーのコンテンツ情報（例: 閲覧したConfluenceページのタイトルやJira課題ID）を記録する/しないを選択できます。デフォルトでは記録が有効になっており、例えば「誰がどのページを閲覧したか」が追跡可能ですが、必要に応じてタイトル部分を記録しない設定にすることで監査ログから機密情報を除外できます。この設定変更自体もログに記録され、ガバナンス上透明性が保たれます。

ログデータのエクスポート: Atlassian Cloudは監査ログをCSV形式でエクスポートする機能を提供しています。管理サイトの「Audit log」画面上部にある「Export log」ボタンから、現在フィルタで絞り込んだ結果または全ログをCSVファイルとしてダウンロード可能です。このCSVにはイベントのタイムスタンプ、実行者、イベント種別、対象、詳細（JSON形式の追加データ）などが含まれます。エクスポート操作は組織管理者およびサイト管理者が実行でき、例えば半年ごとにCSVを保存しておくことで、クラウド上の保持期限を過ぎたログも社内で長期保存できます。ConfluenceやJiraの各サイト管理画面からも同様にCSVエクスポートが可能です。「12ヶ月を超えるログを保存したい場合、CSVエクスポートをご利用ください」とドキュメントでも推奨されています。

REST APIによる取得: 監査ログはプログラムから取得・統合することも想定されています。Atlassianは組織管理APIの一部として監査ログを取得するRESTエンドポイントを公開しています。組織IDとAPIキーを用いて認証リクエストを送ると、指定期間内の監査イベント一覧をページング形式で取得できます。これにより社内のSIEM（Security Information and Event Management）システムや監視ツールに定期的にログを取り込むことが可能です。JiraやConfluenceの個別REST APIにも監査レコード取得用のエンドポイントがあり、サイト管理者権限の認証トークンで製品別ログを取得することもできます。たとえばJira Cloud REST APIの/auditエンドポイントでプロジェクト単位の監査履歴を引く、といった使い方が可能です。

Webhook連携によるストリーミング: さらに高度な連携オプションとして、Webhookを利用したリアルタイム送信があります。Atlassian Accessでは組織監査ログについてWebhook先URLを1件登録でき、以降ログイベントが発生するたびにそのURLへHTTP POSTリクエストが送信されます。送信されるデータはJSON形式で、イベントの内容がペイロードに含まれます。Webhookはイベント発生時に即時実行され（重複イベントは短時間内にまとめて送信される調整あり）、送信失敗時は最大3回まで再試行されます。管理者は管理サイトの「Audit log -> Settings -> Webhook」タブでWebhook URLと認証ヘッダ（必要なら）を登録できます。この機能により、SplunkやDatadog等のログ分析基盤、SIEM製品に対してリアルタイムにAtlassian監査イベントを集約することができます。例えば公式ドキュメントではSlackやMicrosoft Teamsへの通知、あるいは独自SIEMへのHTTP送信による統合が紹介されています。

エクスポート/連携のまとめ: Enterpriseプランではこれらエクスポート・API・Webhook機能を駆使することで、クラウド上の監査データを社内の監査基盤やログストレージと統合し、長期保存や高度な検索分析が可能になります。ログ出力にはユーザーの閲覧操作まで含まれるため、必要に応じWebhook先でフィルタリングやマスキング処理を施すことも検討してください。最後に、監査ログ自体も機密情報を含むため、Atlassianは組織監査ログデータのデータレジデンシー（保存先リージョン指定）は未対応である点に留意が必要です。機密データを含む可能性がある場合、上述の設定でタイトル等を除外するか、自社SIEM側で暗号化保管するなどの対策を講じることが推奨されます。

参考文献: 本調査で取り上げた内容は全てAtlassian公式ドキュメントに基づいています。Atlassian Cloud Enterpriseのセキュリティ機能（アクセス制御・監査ログ）は、公式サポートサイトの「セキュリティとアクセスポリシー」「ユーザープロビジョニング」および各製品のCloudドキュメントに詳細が記載されています。Enterpriseプランをご利用の場合、これらの機能をフル活用することで大規模組織の安全なクラウド運用とコンプライアンス遵守を実現できます。

Sources: