ユーザー セキュリティと Atlassian Access

Server から Cloud への移行の計画の開始点として、セキュリティとガバナンスに関する現在の戦略を移行後の組織に置き換えて検討する場合があります。このページを参考にして、現在の Server セットアップと Cloud への移行する際の推奨事項をご確認ください。

現在のユーザー管理のセットアップによっては、すべての Atlassian クラウド製品全体でエンタープライズ グレードのセキュリティと一元管理を実現する、Atlassian Access のサブスクライブを推奨する場合があります。Access では、大規模環境における時間の節約や標準化に加えて、ユーザー アクティビティの可視化と制御を提供します。Softbank や Lululemon などのお客様は Atlassian Access によって、自動化されたユーザー プロビジョニングで管理タスクを単純化しながら、SAML シングル サインオンでユーザーの安全なログインを実現しています。

Cloud 製品にサインアップすると、admin.atlassian.com から組織の管理画面にアクセスできて、ここから Atlassian Access をサブスクライブできます。組織は、企業のドメインのすべてのクラウド ユーザーを管理できる場所を提供します。組織の仕組みの詳細については「Atlassian 組織」をご確認ください。

移行前に、クラウド組織をご確認ください。

現在、このページのコンテンツに影響する変更を導入中です。admin.atlassian.com の組織で、[ユーザー] と [グループ] の各リストが [ディレクトリ] タブにある場合は、改善されたユーザー管理エクスペリエンスを利用できます。改善されたエクスペリエンスの変更については、以下のコンテンツをご参照ください。

内部ディレクトリ (埋め込みの Crowd)

この Server セットアップは、Jira または Confluence からユーザーを管理している、または Jira または Confluence の単一インスタンスで Crowd を使用している場合に適用されます。この場合、Crowd 自体はその他の外部ディレクトリに接続されていません。



移行前のサーバー セットアップ

移行後のクラウド セットアップ

ユーザーおよびグループ管理

管理者は Jira または Confluence からユーザーを追加および削除したり、グループでアクセスを管理したりします。

管理者は Atlassian Cloud 組織 (以前のサイト) からユーザーを追加および削除したり、グループでアクセスを管理したりします。

ユーザー ログイン

ユーザーはローカルのユーザー名とパスワードでログインします。

ユーザーはメール アドレスとパスワードで自身の Atlassian アカウントにログインします。

これには Atlassian Access は不要ですが、Access が組織を安全に保つ仕組みによるメリットを得られる場合があります。Access に含まれるセキュリティ機能については「Atlassian Access のセキュリティ ポリシーと機能」をご参照ください。

このセットアップでは、移行後にサイト レベルでユーザーとグループを管理できます。

LDAP 認証を使用した内部ディレクトリ (Microsoft AD)

この Server セットアップは、Jira または Confluence からユーザーを管理しているが、他の接続された Server ソフトウェアが ID 情報を使用できるように LDAP によってパスワードを保存している場合に適用されます。



移行前のサーバー セットアップ

移行後のクラウド セットアップ

ユーザーおよびグループ管理

管理者は Jira または Confluence からユーザーを追加および削除したり、グループでアクセスを管理したりします。

管理者は Atlassian Cloud 組織 (以前のサイト) からユーザーを追加および削除したり、グループでアクセスを管理したりします。

ユーザー ログイン

ユーザーは LDAP 認証情報に対して認証するための、1 組のログイン認証情報を持っています。

管理者は SAML シングル サインオンを構成して、認証を一元的に管理し、ユーザーがアイデンティティ プロバイダーでログインできるようにできます (Access が必要です)。

SAML シングル サインオンを構成するには Atlassian Access が必要です

一元的に認証を管理するには、アイデンティティ プロバイダーを使用して Atlassian 組織に SAML シングル サインオンを構成できます。

アトラシアンでは次の Cloud ID プロバイダーによる SAML SSO とユーザー プロビジョニングを公式サポートしています。

  • Okta

  • Azure AD

  • AD FS (Active Directory Federated Services) (SSO のみ)

  • Google Cloud Identity

  • Onelogin

  • Idaptive (旧称 Centrify) (SSO のみ)

ID プロバイダをお持ちではない場合、Atlassian では Okta とのパートナーシップによって無料アカウントを提供しています。

外部ディレクトリ

この Server セットアップは、Active Directory または外部 LDAP ディレクトリから同期していて、他の接続された Server ソフトウェアが ID 情報を使用している場合に適用されます。



移行前のサーバー セットアップ

移行後のクラウド セットアップ

ユーザーおよびグループ管理

管理者はユーザーおよびグループのデータを LDAP ディレクトリに保存します。Jira または Confluence でのユーザーおよびグループ詳細への変更は、LDAP ディレクトリで更新されます。

管理者は Cloud ID プロバイダーでユーザー プロビジョニングを構成して、ユーザーとグループを組織に同期します。ID プロバイダーを LDAP または Active Directory に接続できます (Access が必要)。

ユーザー ログイン

ユーザーは LDAP 認証情報に対して認証するための、1 組のログイン認証情報を持っています。

管理者は SAML シングル サインオンを構成して、認証を一元的に管理し、ユーザーがアイデンティティ プロバイダーでログインできるようにできます (Access が必要です)。

ユーザー プロビジョニングと SAML シングル サインオンを構成するには、Atlassian Access が必要です

Cloud で同様の結果を実現するには、Atlassian 組織と ID プロバイダーの間でユーザー プロビジョニングをセットアップします。一元的に認証を管理するには、ID プロバイダーによって Atlassian 組織に SAML シングル サインオンを構成できます。ID プロバイダーをお持ちではない場合、アトラシアンでは Okta とのパートナーシップによって無料アカウントを提供しています。

Crowd を使用した外部ディレクトリ

この Server セットアップは、Crowd によって複数のディレクトリからユーザーを管理して、1 つの場所からアトラシアンの Server または Data Center 製品に対する認証権限を制御している場合に適用されます。



移行前のサーバー セットアップ

移行後のクラウド セットアップ

ユーザーおよびグループ管理

管理者はユーザーとグループを Crowd に保存します。Jira または Confluence でのユーザーおよびグループ詳細への変更は、Crowd ディレクトリで更新されます。

管理者は、Cloud ID プロバイダーで外部ディレクトリのユーザー プロビジョニングを構成して、ユーザーとグループを組織に同期します (Access が必要)。

ユーザー ログイン

ユーザーは 1 セットの Crowd のログイン認証情報を持ちます。これらによって、Crowd に接続されたすべての Atlassian Server と Data Center の各製品 (Jira、Confluence、Bitbucket) にサインインします。

管理者は SAML シングル サインオンを構成して、認証を一元的に管理し、ユーザーがアイデンティティ プロバイダーでログインできるようにできます (Access が必要です)。

ユーザー プロビジョニングおよび SAML シングル サインオンを構成するには、Atlassian Access が必要です

Cloud で同様の結果を実現するには、Atlassian 組織と ID プロバイダーの間でユーザー プロビジョニングをセットアップします。一元的に認証を管理するには、ID プロバイダーによって Atlassian 組織に SAML シングル サインオンを構成できます。ID プロバイダーをお持ちではない場合、アトラシアンでは Okta とのパートナーシップによって無料アカウントを提供しています。

アイデンティティ プロバイダーによる SAML 認証 (G Suite を含む)

この Server セットアップは、ユーザーを内部ディレクトリから管理するか外部ディレクトリから管理するかにかかわらず、Cloud ID プロバイダーまたは G Suite による認証のために SAML シングル サインオンを構成する場合に適用されます。このセットアップでは、Crowd Data Center と他のアトラシアン製品の Server または Data Center バージョンを使用している可能性があります。このセットアップの詳細については「既存のユーザー管理インフラストラクチャに SAML 統合を追加する」をご確認ください。



移行前のサーバー セットアップ

移行後のクラウド セットアップ

ユーザーおよびグループ管理

内部ディレクトリを使用する場合、管理者は Jira または Confluence からユーザーを追加および削除したり、グループでアクセスを管理したりします。

外部ディレクトリを使用する場合、管理者はユーザーとグループのデータを Crowd Data Center または LDAP ディレクトリに格納します。製品でのユーザーおよびグループ詳細への変更は、Crowd または LDAP ディレクトリで更新されます。

ID プロバイダーを使用する場合、管理者は Cloud ID プロバイダーで外部ディレクトリのユーザー プロビジョニングを構成して、ユーザーとグループを組織に同期します (Access が必要)。

G Suite を使用する場合、管理者はユーザーを (G Suite で検証済みのドメインから) Cloud 組織に同期します。選択した Google グループのユーザーが同期されますが、グループ自体は同期されません。組織 (以前のサイト) からグループを手動で作成できます。

ユーザー ログイン

ユーザーは、すべてのアトラシアンのセルフホスト型/Server と Data Center の各製品 (Jira、Confluence、Bitbucket など) のシングル サインオンで使用できる、1 組のログイン認証情報を持ちます。

アイデンティティ プロバイダーを使用する場合、管理者は SAML シングル サインオンを構成して、認証を一元的に管理し、ユーザーがアイデンティティ プロバイダーでログインできるようにできます (Access が必要です)。

G Suite を使用する場合、認証済みドメインのユーザーには Google (SSO) によるログインが要求される場合があります。

ID プロバイダーを使用するには Atlassian Access が必要です。G Suite を利用する場合は不要ですが、Access が組織を安全に保つ仕組みによるメリットを得られる場合があります。Access に含まれるセキュリティ機能については「Atlassian Access のセキュリティ ポリシーと機能」をご参照ください。

Cloud で同様の結果を実現するには、Atlassian 組織と ID プロバイダー間でユーザー プロビジョニングをセットアップするか、G Suite に接続します。一元的に認証を管理するには、ID プロバイダーによって Atlassian 組織に SAML シングル サインオンを構成するか、G Suite に接続できます。ID プロバイダーまたは G Suite を使用しない場合は、ユーザーとグループをサイト レベルで管理できます。

Atlassian Access サブスクリプションのコスト

単一のサブスクリプションで、エンタープライズ レベルのセキュリティと集中管理を追加できます。Atlassian Access のコストと価格に関する詳細についてご確認ください。

詳細情報とサポート

移行をサポートするための多数のチャネルをご用意しています。

その他のヘルプ