リックソフトブログ

2022年08月09日

Atlassianのクラウド環境のユーザ管理とは?〜アカウント要求とAtlassian Accessの利用について〜

Author

古守 komori

古守</mt:Var>

  

こんにちは、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のいずれかの利用を開始すると[組織]、[サイト]、[製品]の3階層構成の環境が提供されます。作成済みの[組織]がある場合、それに対して後から[サイト]と[製品]を追加することもできます。全体的なアカウント管理やセキュリティに関する設定は[組織]の管理画面にて実施できるようになっています。

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


Atlassian Account について

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

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

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


製品の所有権

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


Atlassian Account の所有権

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

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

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


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

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


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

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


アカウント要求後

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


ドメイン認証とアカウント要求のヒント

ドメイン認証は既存のAtlassian Accountに影響を与えない処理なので、実行タイミングを気にする必要はありません。
アカウント要求は、既存のAtlassian Accountに影響がを与える処理なので、実行前にアカウント要求対象の一覧を取得して影響範囲を確認することをおすすめします。

アカウント要求対象の一覧取得

ドメイン認証が完了し、指定したドメインが認証済になるとアカウント要求を促す画面が表示されます。
この画面で「アカウントのエクスポート」をクリックすると、アカウント要求対象をCSV形式でエクスポートできます。このCSVには、各アカウントが利用している製品の情報が含まれます。

アカウト要求画面で「後で」を選択すると、アカウント要求を実行せずに画面を閉じます。
アカウント要求は管理画面からいつでも実行できるので、既存ユーザへ周知した後に改めてアカウント要求を実施することができます。


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

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

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

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


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

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

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

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

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

Atlassian Accessについて

Atlassian AccessはCloud環境の[組織]と管理対象アカウントに対して、高度なセキュリティ機能を提供するサービスです。
サービスを利用する前に[組織]でドメイン認証とアカウント要求を実施しておく必要があります。

原則として以下の要件を満たすアカウントがAtlassian Accessの請求対象となります。

  • アカウント要求済み
  • Atlassianが提供するCloud製品に対してい有効なアクセスを持つ(ライセンスを消費している)

請求対象については細かい除外事項があります。詳細は下記のドキュメントにてご確認ください。

参考:アトラシアン サポート | Atlassian Access の請求の管理


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

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

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

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

  • 接続元IP制限
    一番手軽で効果が高いセキュリティ対策です。但し、接続元が固定できないリモートワーカーが一定数含まれる場合、VPNやPorxyなどを経由してAtlassian Cloudにアクセスことで接続元のIPを固定するといった対策が必要となります。

  • 二段階認証(任意)の設定
    アカウントを所有しているユーザは、自身のAtlassian Accountに対して2段階認証を設定できます。外部ユーザに2段階認証を設定してもらえば、なりすましによる不正アクセスを防げます。但し、組織管理者からは、管理対象外のアカウントがどのようなセキュリティ設定を行っているか確認できないため、厳密な管理は難しいと言えます。

  • プロビジョニング
    IdPに外部ユーザのアカウントを登録して、プロビジョニングを構成することにより、製品アクセス権の追加/削除を自動化することができます。
    外部ユーザの製品アクセス権のコントロールをプロビジョニングに限定して運用することで、製品アクセス権の削除漏れのリスクを低減できます。
    ※外部ユーザのプロビジョニングでは、アカウントの有効化/無効化、プロファイルの同期など、アカウントそのものに直接影響を与えるような処理は実行されません。
    参考:アトラシアン サポート| ユーザープロビジョニング機能

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

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

Cloud Roadmapに記載されている情報は計画であり、リリース予定の日程は前後する可能性があります。
また、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) 

                                   

Atlassian Accessについてはこちらのページをご覧ください

Atlassian Access

詳しく知りたい方はこちらよりお問合せください

お問い合わせ               
                                                             

本情報はブログを公開した時点の情報となります。
ご不明な点はお問い合わせください。

        

お問い合わせ         

  
本ブログのカテゴリ: Atlassian Cloud
  

アトラシアン製品の導入と活用を
成功させたいなら
リックソフトのサポートが
必要です。

サードパーティ製のアドオンもサポート

サードパーティ製のアドオンもサポート

サポート

アトラシアン社ではサポート範囲外となっているサードパーティ製のアドオンをリックソフトのサポートではサポートします。

  • アトラシアン製品とサードパーティ製のアドオンとの事象の切り分け
  • 海外のアドオンベンダーとのやり取りを代行(日→英/英→日)

リックソフトのサポートは開発元が提供するサポート以上の価値があります。

サポートについて

ツールの活用を促進するアイテム

ツールの活用を促進するアイテム

各種ガイドブック

ツールを導入しただけでは成功とはいえません。利用者が効果を感じていただくことが大切です。独自で制作した各種ガイドブックはツール活用を促進します。

リックソフトからライセンス購入を頂いたお客様にはガイドブックを無料進呈いたします。

ガイドブックについて

価値あるツールの使い方

価値あるツールの使い方

研修・トレーニング

ツール操作の研修だけでなく「ウォータフォール型開発」「アジャイル型開発」のシミュレーション研修も提供。

日本随一の生産性向上にも効果のある研修サービスです。

リックソフトからライセンス購入を頂いたお客様には無料招待や割引特典がございます。

研修について

資料ダウンロード お問い合わせ PAGE TOP
資料ダウンロード お問い合わせ