[Atlassian Access] "What's new in Atlassian Access" ウェビナーのリソースとQ&A

[#1]

※本記事は、Sandyによる英語記事「Resources + Q&A from "What's new in Atlassian Access" webinar」を翻訳したものです。内容に相違が見受けられる場合、英文ページの内容を正とします。

こんにちは。

先日はWhat’s new in Atlassian Accessウェビナーにご参加いただきありがとうございました。Accessの既存の機能や新しくリリースされた機能について、たくさんの質問をいただきました。ここでは、ウェビナー中に回答した質問や、ウェビナーの内容に関連するリソースをご紹介します。

以降の質問は次のカテゴリに分けられています。

• 認証ポリシー/認証設定/SAML SSO

• 製品の自動発見/シャドーIT

• 外部ユーザー/外部アカウント

• AccessとJira、Confluence、JSM、Trello、Bitbucketなど

• ユーザー管理/ユーザープロビジョニング/SCIM

• ドメイン/サブドメイン

• その他 (API、BYOK、CASB、監査など)

• 移行/クラウド移行

• 請求/価格

ウェビナーをご自身のペースでオンデマンドで視聴していただける録画を提供しています。

---

Atlassian Accessの主要なリソース

• 製品デモ: Atlassian Accessの利用を開始する

   - Accessの各機能の30分のデモ (英語)

• Accessの製品ガイド - Accessの各機能の概要、メリット、仕組み

• サポートドキュメント: アイデンティティプロバイダーでSAMLシングルサインオンを構成する

• サポートドキュメント: ユーザープロビジョニングを理解する

ウェビナーで網羅した新機能の詳細を確認できるリソース

• 認証ポリシー - 製品ガイド | サポートドキュメント | ブログ

• 製品の自動発見 - 製品ガイド | サポートドキュメント

• アイデンティティプロバイダー - Google Workspace | Ping Identity

• Statuspage - サポートドキュメント

• 組織のインサイトの2段階認証のグラフ - 製品ガイド | サポートドキュメント

• CASB連携 - 製品ガイド | McAfee MVISION

• ドメイン認証プロセス - サポートドキュメント

• 外部ユーザーのプロビジョニング - サポートドキュメント

---

認証ポリシー/認証設定/SAML SSO

1. アイデンティティプロバイダーのユーザーグループに基づいて認証ポリシーを割り当てることはできますか? いいえ、ユーザーを認証ポリシーに割り当てるためにグループを使用することはできません。ただし、アトラシアンではユーザーを認証ポリシーに割り当てる際の効率性を向上させる方法を検討していきます。この機能リクエストはACCESS-1041で追跡しています。

2. 自社で利用しているアイデンティティプロバイダーがサポート対象かどうかはどのように確認できますか? AD FS、Azure AD、Auth0、Google、Idaptive、Okta、OneLogin、およびPingがサポート対象のアイデンティティプロバイダーです。Atlassian AccessはSSO用の標準SAMLプロトコルに従っているため、ご利用のアイデンティティプロバイダーがこの一覧に含まれていない場合であっても引き続きそれをAccessに接続していただけます。詳細については弊社のドキュメントをご確認ください。

3. 認証ポリシーやセキュリティ機能を触ってみたいのですが、Accessを試用することはできますか? もちろんです！Atlassian Accessは無料で30日間試用できます。認証ポリシーを含むAccessのすべての機能のメリットを完全に活用するには、社内のドメインを認証することをおすすめします。セットアップ手順のドキュメントをご確認ください。

4. Access経由で認証するユーザーにはワンタイムパスワード (OTP) が送信されるのでしょうか? Accessを使用すると、管理対象アカウントに2段階認証を強制できるようになります。管理対象アカウントのユーザーは、スマートフォンにログイン認証アプリ (Google Authenticator、Authy、Duoなど) をログインするか、テキストメッセージで6桁のコードを受け取る (OTP) かを選択できます。ユーザーがOTPを使うことにした場合、Atlassianアカウントへの認証を行う際にOTPを入力するように求められます。

5. Atlassian Accessを使用し、アイデンティティプロバイダーのユーザーにSSOを強制して彼らを認証しつつ、製品へのアクセスはプロビジョニングしないようにすることはできますか? ユースケースとして、Confluenceサイトの有料ライセンスを消費せずに公開スペースの匿名/読み取り専用アクセスのみを行わせたい内部ユーザーがいます。はい、SAML SSOはSCIMユーザープロビジョニングと独立して構成できます。組み合わせることで多大なメリットを発揮しますが、それぞれは独立した機能です。ユーザーをプロビジョニングした場合も、彼らがアトラシアンのクラウド製品を使用しているときにのみ有料ライセンスを使用する点にご注意ください。つまり、お知らせいただいた例で、ユーザーが製品アクセスを持たずに公開Confluenceページの閲覧のみを行う場合、そのユーザーをプロビジョニングしても有料ライセンスは消費しません。

6. 組織管理者がSSOを強制したが、ユーザーがその事実を知らない場合、どうなりますか? 現時点では、ユーザーのSSOを有効化すると、変更の通知がユーザーに送信されます。なお、セキュリティポリシーの変更を適用する前に、内部の変更管理プロセスを処理して適切なメッセージングを行うことを強く推奨します。

7. ユーザーが複数のポリシーに追加された場合、どうなりますか? 1人のユーザーは一度に1つの認証ポリシーにのみ所属できます。詳細については弊社のドキュメントをご確認ください。

8. パスワード要件をデフォルトで “強い“ または “弱い“ に設定することはできますか? デフォルトのパスワード要件は “弱い“ に設定されています。ただし、SAML SSOを有効化すると、アトラシアンのパスワードポリシーは適用されなくなります。

9. あるユーザーを1つのポリシーから別のポリシーに移動する必要があるときに、何千人ものユーザーがいると、対象のユーザーを見つけるのが困難です。ユーザーを素早く見つけて別のポリシーに移動させる方法はありますか? ユーザーを新しい認証ポリシーに追加するだけで、そのユーザーは古い認証ポリシーから自動的に削除されます。ユーザーを名前で検索することも、メールアドレスを含むCSVファイルをアップロードすることで新しいポリシーに一括追加することもできます。

10. Atlassian AccessでSAML SSOを利用する場合、G SuiteからOffice 365への移行パスはどのようなものになりますか? O365のSAML SSOをゼロから構築できます。これにより、ユーザーはGoogleではなくAzure ADにリダイレクトされるようになります。SAML SSOを利用するにはAtlassian Accessのサブスクリプションが必要です。

11. 認証ポリシーを特定の権限スクリプト/JiraまたはConfluence内のプロジェクトやスペースに合わせることはできますか? それとも、これらはアプリケーションごとのグローバルアクセスを制御するのでしょうか? 認証ポリシーは組織レベルでのみ存在するという意味でグローバルです。現時点で、これらをJiraのプロジェクトやConfluenceのスペースに自動的に合わせる機能は提供していません。

12. セキュリティ機能を除外するための認証ポリシーにユーザーを追加した際、それらのユーザーに対して2FAが自動的に無効化されないことがあります。”除外” ポリシーに追加されたユーザーに対しては2FAが自動的に無効化されるのが理想です。これはどのように行なえますか? 2FAが認証ポリシーによって自動的に無効化されることはありません。認証ポリシーは、2FAを必須にするかどうかのみを指示します。2FAが必須ではない場合も、ユーザーは2FAを独自に設定できます。

13. 正規表現に基づき、ユーザーをデフォルトのポリシーではなく認証ポリシーに自動的に追加することはできますか? 現時点ではできません。ユーザーをポリシーに追加する方法は、(1) 名前入力による手動追加または (2) メールアドレスを含むCSVファイルをアップロードする一括追加のみです。

14. ユーザーをドメインにかかわらず弊社のアイデンティティプロバイダーを通じて認証させることはできるようになりますか? いいえ、ご自身で管理していないアカウントの認証方法を制御することはできません。ただし、アトラシアンでは外部ユーザーのセキュリティ制御に取り組んでいます。これは弊社で公開しているクラウドロードマップに記載されているほか、このチケットをフォローして進捗を追跡していただけます。

製品の自動発見/シャドーIT

1. 製品サイトが作成された場合、組織管理者はそれらに組織管理者として自動的に追加されるのでしょうか? 弊社のユーザーが作成したすべてのサイトは、承認されていない、意図せず作成されたものです。退職済みのユーザーもいます。誰かへの問い合わせを必要とすることなく管理できるよう、発見したサイトにすぐにアクセスできると助かります。ドメインを要求すると、そのドメインのユーザーがアクセスした製品が組織に含まれるようになります。組織管理者は自動的に、組織内に含まれるすべての製品の製品管理者になります。ユーザーが作成した新しい製品インスタンスを発見し、それを管理したい場合、ドメインを認証してそれらを組織に追加することですべての管理権限を利用できます。

2. 退職済みで無効化されたアカウントを持っているユーザーのシャドー製品を削除するにはどうすればよいですか? シャドーのIT製品インスタンスの組織管理者がまだいる場合、製品の発見インターフェイスから彼らに連絡でき、彼らがサイトのサブスクリプションをキャンセルできます。製品インスタンスの組織管理者が残っていない場合、アトラシアンサポートに問い合わせるか、削除済みのユーザーのメールアカウントを再有効化し、そのユーザーとしてログインして、彼らのアカウントを使用してシャドー製品インスタンスを削除することができます。

3. 意図せず作成した製品を削除するようにユーザーに依頼する場合、どのような手順を提供すればよいですか? ステップバイステップのガイドはありますか? 意図せず作成された製品は、自身が製品のサイト管理者 (あるいは組織管理者) である場合に削除できます。これらの権限は、製品の現在の組織管理者が指名できます。サイトまたは組織管理者のロールを得たら、サイトのサブスクリプションをキャンセルできます。

4. 管理対象ユーザーが個別の製品インスタンスをセットアップするのを防止できますか? これはグループ権限で行えるのでしょうか? 現時点で、この機能を利用して、管理対象ユーザーが自身の製品インスタンスを個別にセットアップするのを防ぐことはできません。グループ権限は、製品インスタンスが存在するアトラシアン組織にある現在の製品インスタンスに適用され、他の組織の製品インスタンス (この場合はユーザーが作成した製品) には適用されません。防止機能やプロアクティブな制御機能は弊社のロードマップに含まれています。

5. 管理されていない製品に弊社のドメインアドレスのユーザーが追加されているときに、対象のユーザーがAccessのドメインオーナーのポリシーに従っている旨の警告を表示することはできますか? また、組織管理者が所有済みのドメインに所属している場合、ドメインオーナーによるメッセージや承認機能を提供することはできますか? 現在これを実現する方法を検討しています。

外部ユーザー/外部アカウント

1. 外部アカウントを自動的にプロビジョニング解除することはできますか? (完全に無効化するか、自社のサイト全体に対する “サイトアクセス” を無効化) ご利用のアイデンティティプロバイダーを経由してアトラシアンに同期されている外部アカウントを無効化または削除すると、そのアカウントはIdPのグループから削除されるため、この方法を通じて付与された製品アクセスを失います。これらのアカウントは引き続き “サイトアクセス“ は持ちます。”サイトアクセス” は、サイトのユーザー管理 → ユーザー → <ユーザーの詳細ページ> から、ユーザー単位でのみ取り消すことができます。

2. Accessでプロビジョニングされた外部ユーザーはAccessのライセンスを消費しますか? いいえ。管理対象アカウントのみがAccessの請求に対して計上されます。これは弊社で公開しているクラウドロードマップに記載されているほか、このチケットをフォローして進捗を追跡していただけます。

3. 外部ユーザーが特定の期間ログインしなかった場合に自動的に無効化したりアクセスを取り消したりすることはできますか? 自動的に行うことはできませんが、全ユーザーのCSVをエクスポートし、最終ログイン時刻を確認して、無効化や削除を判断していただけます。

4. 外部ユーザーを管理する際、JSMポータルの外部のカスタマーも管理できますか? はい、JSMポータルへのアクセスを付与するために外部ユーザーをプロビジョニングできます。たとえば、IdPからAtlassian Cloudにユーザーをプロビジョニングし、組織内の全員がアクセスできるようにJSMポータルを構成することができます。

5. 外部ユーザーが自社のSSOにすでにサインアップしている場合、どうなりますか? 彼らをSCIM経由でプロビジョニングできますか? 組織内でSCIMを構成済みで、同期したグループに外部ユーザーが含まれている場合、それらの外部ユーザーのグループメンバーシップがアトラシアンに同期され、ユーザーはグループから製品アクセスを継承します。これはユーザーアカウントのSSO設定に干渉しません。ユーザーはあなたの組織の製品にアクセスする前に引き続き自社のSSO経由でAtlassianアカウントにログインします。

6. 外部ユーザーに対し、内部ユーザーよりも厳しい別のポリシーを適用したいと考えています。あるユーザーグループを “外部” と設定してすべての外部ユーザーをそのグループに割り当てた場合、ポリシーはそのユーザーグループにのみ適用されますか? 認証ポリシーは管理対象アカウントにのみ適用されます。外部アカウントを認証ポリシーに追加することはできません。アトラシアンのチームは外部ユーザーのセキュリティ制御に取り組んでいます。これは弊社で公開しているクラウドロードマップに記載されているほか、このチケットをフォローして進捗を追跡していただけます。

7. 私はアトラシアンパートナーで、弊社のクラウド製品のすべてのクライアントで使用するアカウントを保持しています。私のような外部ユーザーのために新しいポリシーをセットアップするように勧めたほうがよいでしょうか? 認証ポリシーは管理対象アカウントにのみ適用されます。外部アカウントを認証ポリシーに追加することはできません。アトラシアンのチームは外部ユーザーのセキュリティ制御に取り組んでいます。これは弊社で公開しているクラウドロードマップに記載されているほか、このチケットをフォローして進捗を追跡していただけます。

8. 外部アカウントのプロビジョニングの自動解除について、製品アクセスに加えてサイトアクセスを無効化することはできますか? “アカウントを持つ全ユーザー” に設定されたサービスデスクなどにアクセスできているようです。それらのユーザーを外部のアイデンティティプロバイダーから同期していて、そのユーザーをアイデンティティプロバイダーで無効化または削除した場合、そのユーザーはAtlassian Accessで無効化されます。ユーザーが無効化された場合、そのユーザーはアカウントにログインすることはできなくなります。これにはサポートデスクへのアクセスが含まれます。ユーザーを無効化せずに製品アクセスを取り消した場合、そのユーザーは引き続きサービスデスクにアクセスできます。

9. 外部ユーザーのアクセスを新しいアカウント (外部ユーザー) にクローン/ミラーできますか? 新しいアカウントを古いアカウントのすべてのグループに追加することで行なえます。

10. 他のドメインで管理されているユーザーにMFAを強制できますか? Accessには現在、組織の外部のユーザーや他の組織が管理しているドメインのユーザーに対して認証ポリシーを強制する機能はありません。ただし、この機能は弊社の検討対象になっています。タイミングを明言することはできませんが、人々に必要とされている機能であることは理解しています。jira.atlassian.comにフィードバックをお寄せください。

AccessとJira、Confluence、JSM、Trello、Bitbucketなど

1. Jira Cloud PremiumとConfluenceを使用している場合、Atlassian Accessを使用することにどのようなメリットがありますか? Cloud PremiumプランをAtlassian Accessと組み合わせることで、優れたメリットを活用できます。現在Cloud Premiumプランを検討中の場合、組織が成長を続けていて、スケール方法や自社データの保護方法をお探しかと思います。Atlassian Accessにより、アイデンティティプロバイダーを接続して管理対象ユーザーにSAMLシングルサインオンを強制して、強化されたセキュリティレイヤーを追加できます。また、そのアイデンティティプロバイダーを活用してSCIM経由でユーザーをプロビジョニングし、ユーザーのライフサイクル管理のスケールに役立てることもできます。

2. サービスデスクのカスタマーがログインするときにセキュリティ多段階認証 (MFA) を適用できますか? MFAは管理対象アカウントにのみ適用できます。サービスデスクのカスタマーが組織の管理対象アカウントではない場合、彼らにMFAを強制することはできません。.

3. AccessをTrelloに使用できますか? はい。ドメインの認証後、組織管理者は管理対象アカウントの一覧と、彼らのなかでTrelloへの製品アクセスを持つアカウントを確認できます。Atlassian Accessサブスクリプションにより (ユーザーが請求対象外ポリシーに含まれていない場合)、Trelloアクセスを持つユーザーを含むすべての管理対象ユーザーに認証ポリシーを強制できます。

4. 多くの人がTrelloアカウントを保持しています。組織はどのようにユーザー数を管理すればよいのでしょうか? Trelloのみを使用しているユーザーのための支払いを必須にしたくはありません。これは弊社が現在積極的に取り組んでいる領域です。弊社の製品設計のパートナーとして、お客様のユースケースや、Trelloのユーザー数およびワークスペースの制御方法をお知らせいただける場合、このチケットをフォローしてください。現時点では、Trelloのみを使用しているユーザーを請求対象外のAccessポリシーに移動させることができます。これによってAccessのポリシー強制からも除外されます。

5. アトラシアンの管理画面でのTrelloユーザーの管理について、どのような機能が開発されていますか?
    Trelloの製品アクセスを管理するためにユーザーのAtlassianアカウントを無効化せずに済むよう、現在admin.atlassian.comでのTrello管理について、積極的に調査しています。この作業の進捗を追跡したい場合はこのチケットをフォローしてください。Trelloの管理について、弊社の設計パートナーになっていただける管理者を募集しています。

6. Atlassian AccessはBitbucket Cloudをサポートしますか? AccessでBitbucketユーザーを管理できますか? はい。Atlassian AccessでBitbucketユーザーに対して利用できる機能をこちらのページで確認していただけます。

7. Bitbucketへのユーザーのプロビジョニングはいつ行えるようになりますか? Bitbucketのユーザーやグループの管理を一元化する予定はありますか? 恐縮ながら、現時点でご案内できるタイムラインはありません。現時点ではBitbucketよりもTrelloについて、スコープを調査して作業を行っています。なお、アイデンティティプロバイダーでアカウントが無効化されるとグローバルのAtlassianアカウントも無効化され、ユーザーはすべてのクラウド製品へのアクセスをまとめて失うため、プロビジョニング解除は動作する点にご注意ください。

8. Atlassian AccessでのJira Alignのサポートへの取り組みはどうなっていますか? お客様の組織でこの機能が必要な場合、このチケットで投票して進捗を追跡してください。

ユーザー管理/ユーザープロビジョニング/SCIM

1. ユーザーとグループがアイデンティティプロバイダーでプロビジョニングおよび管理されている場合、Atlassian Accessを使うことにメリットはありますか? はい。Atlassian Accessを使用すると、JiraやConfluenceなどのアトラシアンのクラウド製品にアイデンティティプロバイダーを接続し、ユーザーのプロビジョニングやプロビジョニング解除を自動化したり、ユーザーにSAML SSOでのログインを強制したりすることができます。

2. Atlassian Accessでのユーザーの自動プロビジョニング解除について詳しく教えてください。 Atlassian Accessを使用してご利用のアイデンティティプロバイダーをクラウド製品に接続すると、SCIMプロトコルを活用してユーザーのライフサイクル管理を自動化できます。ユーザーがアイデンティティプロバイダーでチームに参加したり、チームを離れたり、チームを移動したりすると、それがアトラシアンのクラウド製品の権限に自動的に同期されます。詳細をこちらでご確認ください。

3. Atlassian Accessでは、AzureのグループをJira Cloudに同期して、それらのグループに所属するユーザーを継続的に同期させることはできますか? はい。SCIM経由のユーザープロビジョニングをセットアップすることで、Azure ADから組織内の任意のJiraインスタンスにグループとユーザーをプロビジョニングできます。SCIM連携を無効化しない限り、ユーザーとグループはアイデンティティプロバイダーと継続的に同期されます。詳細を弊社のドキュメントでご確認ください。

4. 電話番号、オフィス所在地、上長などの追加のActive Directory属性を取り込みたいです。これはロードマップにありますか? この機能は現在弊社のロードマップにはありません。現時点では、表示名、メールアドレス、組織、職名、タイムゾーン、部門、言語のフィールドをプロビジョニングできます。

5. 管理者がユーザーを管理するために利用できるディレクトリは、機能がとても限られています。アクティビティのタイムスタンプを表示して並べ替えられるようにする予定はありますか? また、一括での無効化ができると助かります (特に、Trelloの古い無料アカウントがある場合)。 管理対象アカウントのページの個々のアカウントの画面では最後にアクティブだった時刻のタイムスタンプを確認できますが、現時点でこれを並べ替えることはできません。一括での無効化はUIで行えますが、大規模な一括操作やカスタムでの並べ替えについては管理APIの使用を推奨します。

6. 特定の製品をドメインのユーザーにプロビジョニングできないようにすることはできますか? 現在、ドメインのユーザーが特定のタイプのすべての製品インスタンスを作成したり、それらに参加したりするのを防止することはできません。これは、ユーザーがセットアップした製品は、中央で管理されるIT組織とは論理的に別のアトラシアン組織に所属するためです。しかしながら、管理対象ユーザーの制御機能の改善はロードマップに含まれています。個々の要件について弊社のチームにお伝えしたいことがある場合、この公開チケットをフォローしてください。

7. 特定のサイトをAccessの制御下におくことはできますか? はい、そのユーザーのドメインを要求した場合は可能です。ドメインを要求すると、そのドメインのすべてのユーザーが管理対象アカウントとして取得されます。特定のユーザーにAccessのセキュリティ機能を適用したい場合、彼らを個々の認証ポリシーに追加できます。

8. Cloud Enterpriseでは1つの組織で複数のサイトを持てると理解しています。複数のサイトがある場合、Atlassian Accessでそれらの複数のサイトを横断したユーザーの管理に違いはありますか? Atlassian AccessはCloud Enterpriseのサブスクリプションの一環として提供されています。このため、これら2つのサブスクリプションでユーザーを管理する方法に違いはありません。

ドメイン/サブドメイン

1. ドメイン認証について、弊社のアイデンティティプロバイダーのドメインは私のメールドメインと同じものだと考えています。私は複数のメールドメインを使っており、これにはサブドメインも含まれます。ドメイン認証でこれにどのように対応できますか? アトラシアンのクラウド組織では、管理している複数のドメインやサブドメインを要求できます。詳細を製品ガイドとサポートドキュメントでご確認ください。

2. 組織管理者がドメインを要求してユーザーアカウントが組織で管理されるようになったら、ユーザーには製品内で通知されますか、それともメールが送信されますか? 2021年5月上旬に、ユーザーに送信されるメールをなくす更新をリリースしました。アカウントが組織によって管理されるのを伝えることは引き続き法的な要件であるため、このメッセージはメールではなく製品内のプロフィール設定で表示されるようになりました。

3. 全ユーザーをまとめて管理したくありません。すべてのユーザーに影響を与えることなくドメインを認証することはできますか? ドメイン認証はAtlassian Accessのセットアップにおける必須の手順です。認証ポリシーにより、ポリシーを適用したい一連のユーザーを選択し、残りのユーザーはAccess機能を持たない請求対象外ポリシーに設定することができます。ただし、引き続き、認証したメールドメインのすべての要求済みユーザーを管理することになります。

4. 既存のアカウントが管理対象ドメインのメールアドレスを使うように更新された場合に、アカウントを元のメールアドレスに戻す (管理対象外のドメインベースのメールアドレス) ことはできますか? お客様がアカウントのメールドメインを切り替えたときに構成で問題が発生することがあるため、先日この機能を変更しました。しかしながら、この変更によって新しい問題が生じている旨のフィードバックもいただいています。この機能が必要な場合はこちらにフィードバックを追加してください。

その他 (API、BYOK、CASB、監査など)

1. APIコールのペイロードの一貫としてメールアドレスをどのように表示できますか? ユーザーのメールアドレスは、組織ユーザーを取得するコールのペイロードに含まれます。APIドキュメントをご確認ください。

2. ディレクトリ全体をパースする代わりに既存のユーザーをメールアドレスで検索するAPIコールを利用したいです。 admin.atlassian.comの管理対象アカウントの一覧で、ユーザーをメールアドレスで検索できます。APIの場合、すべてのユーザーを取得してからemailフィールドに対して一致させるのが唯一の方法になります。

3. BYOKはいつサポートされるようになりますか? アトラシアンのチームはBYOKの暗号化やそれを実際に提供する方法を検討しています。これは弊社の公開クラウドロードマップに追加されており、進捗を追跡していただけます。

4. CASBやAzure MCASについてのドキュメントはありますか? Atlassian AccessでのCASB連携の仕組みについての製品ガイドはこちらです。現在、McAfee MVISION Cloudのみをサポートしています。アトラシアンのクラウド製品で活用したいCASBパートナーがいる場合、弊社とともに実装に取り組めるよう、パートナーにこれをお伝えすることを強くおすすめします。

5. 管理者やセキュリティチームのガバナンスやコンプライアンスに役立つ、追加のユーザー監査やレポート機能の予定はありますか? はい、今後は時間をかけて新しい監査ログを追加し続けていくことを予定しています。これは弊社の公開クラウドロードマップに記載されています。今後の数四半期で、課題やページの読み取り、作成、変更、削除に焦点を当てたJiraおよびConfluenceのユーザーイベントが監査ログに追加されます。

移行/クラウド移行

1. サーバーからのクラウド移行にはどのような懸念がありますか? 懸念事項への対応に利用できるリソースを含む移行センターがあります。また、移行を検討しているサーバー製品のお客様から寄せられる上位の懸念事項をこちらにまとめています。ここには、Atlassian Accessやユーザー管理に関連する質問や、Active Directoryまたは既存のLDAPを使っているお客様がユーザーを移行する方法が含まれます。クラウド移行のプロセスを確認したい場合はこちらから移行のeBookをダウンロードしていただけます。

2. 一連のユーザーを新しいインスタンスおよび組織に移行して、メールアドレスを管理対象外から管理対象に更新する必要がある、アクセス権の剥奪のユースケースについて教えてください。これはどのように動作しますか? 組織管理者は、管理するアカウントのメールアドレスを更新できます。管理対象外のアカウントのユーザーのみが、そのアカウントのメールアドレスを管理対象から管理対象外に変更することができます。Atlassianアカウントのメールアドレスの更新の詳細をこちらでご確認ください。

請求/価格

1. 同期したすべてのユーザーに対する請求が発生するのですか、それとも権限を持っているユーザーあるいはアクティブなユーザーでしょうか? 要求したドメインのユーザーのうち、クラウドサブスクリプション (Bitbucket、Trello、Jira、Confluenceなど) に含まれるすべてのユーザーに対する請求が発生します。特定のユーザー/チームをAtlassian Accessの請求対象やAccessの機能の対象に含めたくない場合は、請求対象外ポリシーを作成できます。

2. 自社のメールアドレスでTrelloに登録したが製品を使用したことがないユーザーが請求対象にならないようにするために推奨されるアプローチはありますか? はい、管理対象アカウントに移動して、Trelloのみを使用している、長期間アクティブになっていないユーザーを見つけ、無効化できます。このようなユーザーが多数いる場合、クラウド管理者用のAPIを使ったスクリプトを作り、最後にアクティブになった日付での絞り込みを行ってそのユーザーを無効化するAPIコールを行うことで、プロセスを自動化できます。

3. ヘルプデスクソリューションとしてJira Service Managementを採用し、すべてのエンドユーザーにMicrosoft O365の自社の資格情報を使用してログインさせたい場合、Atlassian Accessの支払いを行う必要がありますか? いいえ、Atlassian Accessの請求はカスタマーではなくヘルプデスクエージェントにのみ発生します。これらのヘルプデスクのカスタマーが、請求対象の他のアトラシアン製品 (Jira、Trello、Confluenceなど) へのアクセスを持たない場合、Atlassian Access経由でのSSOの適用は無料で行えます。