認証ポリシーについて理解する

認証ポリシーによって、組織内のユーザーと設定のセットごとに認証設定を指定できます。Atlassian 組織にアクセスするユーザーの本人確認を行います。

認証ポリシーは、以下のようになります。

1. 既定のポリシー - 新しいメンバーを、ローカルまたは ID プロバイダー ディレクトリにある既定のポリシーに自動で追加します。

2. 請求対象外 - 特定のユーザーに対して支払わない場合は、請求対象外ポリシーを作成します。ローカル ディレクトリでは、請求対象外ポリシーは既定のポリシーとしてのみ設定できます。

3. ローカル ディレクトリ - ID プロバイダーで管理していないメンバーが含まれます。これらのユーザーを招待するか、ユーザー自身がサイン アップします。

4. 2 段階認証 - ログイン時に 2 段階の認証を求めるか、メンバーに対してはそれを任意にします。

5. パスワード要件: パスワードの強さと有効期限の最低要件を追跡します。

6. アイドル セッション時間 – メンバーがログアウトされるまでの非アクティブ状態の継続時間を追跡します。

7. メンバー - ポリシーのメンバー数を表示します。メンバーを、あるポリシーから別のポリシーに追加または移動します。

8. SSO (シングル サインオン) - SAML または Google Workspace SSO を介した Atlassian へのログインをいつ強制するタイミングを追跡します。SSO は、ID プロバイダー ディレクトリでのみ強制できます。

9. ID プロバイダー ディレクトリ - ID プロバイダーを介して同期または認証するユーザーが含まれます。メンバーを認証ポリシー間で追加および移動できます。

このビデオで認証ポリシーの詳細をご確認ください

設定の編集やメンバーの追加に関する詳細

複数の認証ポリシーのための Atlassian Access

組織は、1 つのポリシーで運営できます。ユーザーのサブセットに対して複数のポリシーを適用し、組織全体にロール アウトする前に設定をテストできるため、柔軟性があります。

複数の認証ポリシーを作成するには、Atlassian Access サブスクリプションが必要です。Atlassian Access の詳細をご確認ください

認証ポリシーのユース ケース

組織を管理するため、複数のポリシーを作成して、複数のユーザー セットのセキュリティに対応します。また、ユーザーのサブセットの設定をテストします。小さいユーザーのセットで設定をテストする場合、組織全体には機能しない可能性があるポリシーのロール アウトは避けます。

組織に対して最大 20 のポリシーを作成できます。

次に示すのは、組織に対する認証ポリシーの使用方法の例です。

複数のユーザーのサブセットに対する複数のポリシー

ユーザーによって、認証のニーズは異なります。そのニーズに対応するため、組織内のユーザーのサブセットそれぞれに対してポリシーを作成います。これは、複数のポリシーを作成することを意味します。

たとえば、以下の手順が可能です。

• 正社員、請負業者、C-Suite、パートナーなど、特定の一連のユーザーにさまざまなポリシーを作成します。

• ボット アカウント用の認証設定をカスタマイズします

• 請求対象外ポリシーを作成して Atlassian Access のサブスクリプション コストを管理する

認証設定のテスト

リスクを軽減して、公開前にユーザーのサブセットの設定をテストできる必要があります。

たとえば、以下の手順が可能です。

• ユーザーのより小さいサブセットで 2 段階認証をテストして、組織間でロールアウトする前に正しく設定されていることを確認します。

• 管理テスト アカウントごとに異なるポリシーを設定することで、SSO をテストします。それによって、ログインしてポリシーのトラブルシューティングを実施できます。

デフォルト認証ポリシーとは何ですか?

管理対象アカウントは、認証ポリシーのためのユーザーのプールがあります。ポリシーのメンバーとなるユーザーを割り当てます。組織には、まずデフォルト認証ポリシーが適用されます。デフォルト ポリシーには、メンバーのログイン設定が含まれます。新しい管理アカウントをプロビジョニングする場合、デフォルト ポリシーにメンバーとして追加します。

現在、既定のポリシーを請求対象外ポリシーにできます。

他のポリシーをデフォルト ポリシーにするには:

1. admin.atlassian.com に移動します。複数の組織がある場合は、組織を選択します。

2. [セキュリティ] > [認証ポリシー] の順に選択します。

3. デフォルトにするポリシーの [編集] を選択します。

4. [Make default policy (デフォルト ポリシーを作成する)] を選択します。

ポリシーを削除するには:

1. admin.atlassian.com に移動します。複数の組織がある場合は、組織を選択します。

2. [セキュリティ] > [認証ポリシー] の順に選択します。

3. 削除するポリシーの [編集] を選択します。

4. [Delete policy (ポリシーを削除する)] を選択します。

請求対象外ポリシーとは

ユーザーが手動で招待されるか、自分でサインアップする場合、そのユーザーを Atlassian Access サブスクリプションに含めるかどうかを決定できます。

Atlassian Access サブスクリプションでは、特定のユーザーを支払い対象に含めたくない場合に、請求対象外ポリシーを作成できます。請求対象外ポリシーのユーザーについては請求しません。設定できる請求対象外ポリシーは 1 つだけです。

既定のポリシーを請求対象外ポリシーに設定できます。請求対象外ポリシーはローカル ディレクトリにのみ作成できます。

ディレクトリの詳細

認証ポリシーを編集してポリシーを請求対象外にする際は、次を実行できなくなります。

• シングル サインオンを強制

• 2 段階認証を要求

• ID プロバイダー (Okta、Azure AD、G Suite など) からポリシーに同期するユーザーを追加

ポリシーを簡単に更新して、すべてのセキュリティ設定を含められます。一度実行すると、ポリシーのユーザーは Atlassian Access の請求書にカウントされます。

ポリシーを請求対象外にするには、以下の手順に従います。

1. admin.atlassian.com で [認証ポリシー] に移動します。

2. 請求対象外にするポリシーの [編集] を選択します。

3. [ポリシーを請求対象外にする] を選択します。

請求対象外ポリシーをすべてのセキュリティ設定に更新するには、次の手順に従います。

1. admin.atlassian.com で [認証ポリシー] に移動します。

2. 請求対象外ポリシーの [編集] を選択します。

3. [すべてのセキュリティ設定をポリシーに追加] を選択します。

4. ポリシーを更新します。

既定ポリシーを請求対象外にするには

手動で招待されたユーザーや、自分でサインアップしたユーザーを Atlassian Access サブスクリプションにカウントさせたくない場合は、そのユーザーを既定の請求対象外ポリシーに自動で追加できます。

請求対象外ポリシーを既定ポリシーにする前に、ローカル ディレクトリに必要なユーザー アカウントのドメインをリンクする必要があります。リンクしたドメインの新しいユーザー アカウントは、ローカル ディレクトリの既定の認証ポリシーに追加されます。

ドメインをディレクトリにリンクするには、次の手順に従います。

1. admin.atlassian.com に移動します。複数の組織がある場合は、対象の組織を選択します。

2. [セキュリティ] > [ID プロバイダー] の順に選択します。

3. 表示するディレクトリを選択します。

4. [ドメインを表示] を選択して、ドメインをローカル ディレクトリにリンクします。

5. [ドメインをリンク] を選択します。

6. ローカル ディレクトリにリンクする 1 つ以上のドメインを選択します。

ポリシーを請求対象外にするには、以下の手順に従います。

1. admin.atlassian.com で [認証ポリシー] に移動します。

2. ローカル ディレクトリの既定ポリシーに移動します。

3. 既定ポリシーで [編集] を選択します。

4. [ポリシーを請求対象外にする] を選択します。