こんにちは、Ricksoft プリセールスの古守です。

今年は、Atlassianにとって創業20周の節目となる年で、これに因んだプレスリリースやブログが公開されています。なかでもAtlassianの共同創業者、スコット・ファークァー氏とマイク・キャノンブルックス氏による「アトラシアン20年の軌跡とこれからのこと− 戦略、価値、永続的な企業づくりに関する20の教訓−」がとても興味深く面白い内容でした。

Atlassian はここ数年の間にSaaS企業として広く知られるようになりましたが、同社のSaaSの歴史は古く、2008年にAtlassian hostedというブランドで顧客向けにツールの一部をホスティングしたのが始まりでした。2011年にAtlassian Ondemand（現在のAtlassian Cloud ）を立ち上げ本格的にSaaSビジネスを開始し、以降はSaaS関連の企業買収、基盤やソフトウェアの開発などに大規模な投資が続けられてきました。

私がRicksoftに入社した2015年頃は、Jira Cloud、Confluence Cloud は速度が遅く、時々アクセスできなくなることがありましたが、現在は安定性やパフォーマンスの問題が大幅に改善され、魅力的な機能が多数提供されています。

企業向けの管理機能も充実していますが、ユーザ管理まわりの設定についてよくご質問をいただきます。
今回は、特に問い合わせが多いアカウント要求とAtlassian Accessの利用について簡単に説明したいと思います。

Cloud環境の構成

AtlassianのCloud製品Jira 製品 (Jira Software、Jira Service Management、Jira Work Management)、Confluence Cloud、Statuspage、Opsgenieのいずれかの利用を開始すると［組織］、［サイト］、［製品］の３階層構成の環境が提供されます。作成済みの［組織］がある場合、それに対して後から［サイト］と［製品］を追加することもできます。全体的なアカウント管理やセキュリティに関する設定は［組織］の管理画面にて実施できるようになっています。

参考：アトラシアン サポート | アトラシアンの組織とは

Atlassian Account について

AtlassianのCloud製品を利用する際、最初にメールアドレスをキーとするアカウントを作成します。
このアカウントのことをAtlassian Accountと言います。

Cloud製品の利用者は、Atlassian Accountを使ってAtlassianのCloud 環境にログインし、アクセス権が付与された製品を利用することができます。
TrelloとBitbucketはAtlassian Cloud の［組織］に紐付けられていませんが、Atlassian Accountを使って製品にアクセスします。

Atlassian Accountを無効化するとCloud製品に対する全てのアクセスを無効化できます。

製品の所有権

ここでは便宜上、［組織］の管理の権限を持つユーザを「製品の所有者」と呼びます。製品所有者は下記の設定ができます。

• 製品アクセス権の追加／削除
  Atlassian Accountに対して製品アクセスを許可したり、禁止したりできます。
  
• 接続元IP制限
  指定したIPアドレスからアクセスされた場合のみ、製品への接続を許可するように制限をかけることができます。
  

  参考：アトラシアン サポート | 製品アクセス用の IP アドレスを指定する

Atlassian Account の所有権

Atlassian Account は、Atlassianのサイトからサインアップしたり、Cloud製品を利用しているユーザから製品に招待されることによって作成されます。デフォルトでは、Atlassian Accountのメールアドレスに紐づくユーザがアカウントの所有者と見做されます。

［組織］の管理者であっても所有権を持たないアカウントに対して、下記のような操作や設定はできません。このため、Atlassian Acountの所有権を個々のユーザから［組織］の管理者に移譲する仕組みが提供されています。

• パスワードポリシーの強化
• ログイン認証方式の指定（SAML認証や2段階認証の強制）
• アカウントのプロフィアル情報の変更
• アカウントの有効化・無効化・削除

ドメイン認証＆アカウント要求

Atlassian Cloudでは「ドメイン認証」と「アカウント要求」の２つの処理を実施することで、アカウントの所有権を個々のユーザから［組織］の管理者に移譲できます。

参考：アトラシアン サポート| 組織のドメインを認証する

参考：アトラシアン サポート｜ドメインのアカウント クレームとは?

アカウント要求後

組織の管理者は所有権を取得したアカウントに対して、変更を加えることができるようになります。一方、アカウントのメールアドレスに紐づく個々のユーザは、アカウントの所有権を失うため、自身でアカウントを削除したり、メールアドレスを変更したりできなくなります。

管理対象アカウントと 管理対象外のアカウント

アカウント要求により、［組織］の管理者に所有権が移譲されたAtlassian Accountを「管理対象アカウント」と呼びます。一方、組織の管理対象となっていないAtlassian Accountは管理対象外のアカウントとなります。

例えば、RICKSOFTの組織管理者から見た場合、管理対象アカウントはricksoft.jp ドメインのアカウントのみで、これ以外は管理対象外のアカウントとなります。

視点を変えて、MKTDEVの組織管理者から見た場合、管理対象アカウントはmkt.rsdev.jpドメインのアカウントのみで、これ以外は管理対象外のアカウントとなります。
このように自分の[ 組織]から見ると管理対象外アカウントであっても、ドメインを所有する[組織]にて「管理対象アカウント」として管理されている可能性があります。

管理対象アカウントの管理

［組織］の管理者は、管理対象アカウントに対して以下のような変更を加えることができます。

• アカウント情報（表示名やメールアドレスなど）の閲覧と編集
• パスワードポリシーの設定
• アカウントの有効化、無効化、削除
• セッション期間の設定

また、Atlassian Accessをサブスクライブすることで以下の設定ができます。

• AzureADやOktaなどのIdP製品との統合
  • SSO（SAML2.0）
  • プロビジョニング（SCIM）
• Atlassianが提供する２要素認証の強制
  
  

管理対象外のアカウントの取り扱い

Atlassian Cloud環境の［組織］では、Atlassian Accountに対して、SAML認証や２段階認証といったログイン認証方式を割り当てる仕組みが提供されています。
この設定には、Atlassian Acountの所有権が必要となるため、管理対象外のアカウントに対してSAML認証や2段階認証を強制することができません。

協力会社などの外部ユーザに対して、SAML認証や2段階認証を適用したい場合は、外部ユーザ向けに認証済ドメインのメールアドレスを発行し、管理対象アカウントに加えるしかありません。この方法のデメリットは、メールアカウントの発行などに追加のコストがかかってしまう点です。

このような対応が難しい場合、製品所有者が制御できる範囲でセキュリティ対策を講じることになります。
下記に考えられる対策を記載します。

• 接続元IP制限
  一番手軽で効果が高いセキュリティ対策です。但し、接続元が固定できないリモートワーカーが一定数含まれる場合、VPNやPorxyなどを経由してAtlassian Cloudにアクセスことで接続元のIPを固定するといった対策が必要となります。
  
  
• 二段階認証（任意）の設定
  アカウントを所有しているユーザは、自身のAtlassian Accountに対して２段階認証を設定できます。外部ユーザに２段階認証を設定してもらえば、なりすましによる不正アクセスを防げます。但し、組織管理者からは、管理対象外のアカウントがどのようなセキュリティ設定を行っているか確認できないため、厳密な管理は難しいと言えます。
  
  
• プロビジョニング
  IdPに外部ユーザのアカウントを登録して、プロビジョニングを構成することにより、製品アクセス権の追加／削除を自動化することができます。
  外部ユーザの製品アクセス権のコントロールをプロビジョニングに限定して運用することで、製品アクセス権の削除漏れのリスクを低減できます。
  ※外部ユーザのプロビジョニングでは、アカウントの有効化／無効化、プロファイルの同期など、アカウントそのものに直接影響を与えるような処理は実行されません。
  参考：アトラシアン サポート| ユーザープロビジョニング機能
  
  

Enterprise向けのSaaSにおいて、ドメイン認証とアカウト要求を実行してアカウントの所有権を得るという仕組みは珍しいものではありません。しかし、多くのSaaS製品では、製品インスタンスやワークスペースなどの特定の領域にアクセス（ログイン）する際にSAML認証を適用できる仕組みを提供しています。つまり、アカウントの所有権が無くても、製品の所有権（管理者権限）があればすべての利用者に対してSAML認証を強制できるのです。

Atlassian Cloudでも2022年12月頃までにJira Cloud 、Confluence Cloudにアクセスする際に２段階認証を求める機能をリリースする計画があります。 この機能が提供されると管理対象外のアカウントに対して、製品アクセスのタイミングで2段階認証を強制できるようになります。

まとめ

今回はアカウント管理に関する必要最小限の内容のみ記載しました。細かい内容については関連ドキュメントを確認して少しずつ理解を進める必要があります。
まずは、以下の観点を押さえることでアカウント管理に関する仕組みを理解しやすくなると思います。

• アカウントの所有権が必要となる操作・設定
• Atlassian Accessが提供する機能

現在、Cloud環境はEnterprise向けの機能開発が急ピッチで進められており、アカウント管理まわりの仕様が新しい仕組みに切り替わる過渡期にあると言えます。本記事の最後に参考情報として今後リリースが計画されている主要な変更について記載しました。興味がある方は御覧ください。

参考

今後リリースが計画されているアカウント管理に関する主要な変更は下記の通りです。

既存のクラウドのお客様向けの組織レベルのユーザーとグループディレクトリ（Organization-level user and group directory ）

これまでサイト単位で管理していたユーザ、グループを組織単位で管理できるようにします。
この新しいユーザー管理の仕組みは2021年の第2四半期以降に作成された組織では既に利用できる状態となっています。
これ以前に作成された組織に対しては、2022年Q4〜2023年Q1にかけて段階的にリリースされる計画となっています。

【参考】Atlassian Community: User management for cloud admins just got easier ( English-only)

細分化された管理者ロール（Granular admin roles）

前項の「クラウドのお客様向けの組織レベルのユーザーとグループディレクトリ」 のリリースにより、ユーザの追加やグループのメンバーシップ変更に組織の管理者権限が必要となりました。
組織管理権限でしか実行できない操作が増えた結果、柔軟な運用が難しくなったことから、ユーザ管理、請求管理などのロール毎に権限を付与する機能の追加が計画されています。

【参考】CLOUD-10684: Separate permission for Billing without granting Site admin access ( English-only) 

管理対象外のユーザー セキュリティ（Unmanaged user security）

管理対象外のアカウントに対して、製品アクセス時に2段階認証を要求する機能を提供します。

【参考】 ACCESS-102: Enforce security policies for users not on verified domains ( English-only) 

選択的ユーザー要求（Selective user claim）

指定したユーザのみアカウント要求をかける機能を提供します。これにより、Atlassian Accessの適用対象を限定できるようになります。

【参考】ACCESS-764: Selective user claim ( English-only)

単一組織の複数のアイデンティティ プロバイダーをサポート（Support multiple identity providers for a single organization）

1つの［組織］に対して、複数のIdPを統合する機能を提供します。
※この機能は、Jira 、ConfluenceのEnterpriseプランのみの提供となります。2022年8月現在、段階的にリリース作業が進められています。

【参考】ACCESS-572: Allow multiple Identity Provider(IdP) configurations for a single org and domain ( English-only)