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

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

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

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

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

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

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

5. サードパーティ ログイン – サードパーティ アカウントからのログインを許可またはブロックします。

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

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

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

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

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

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

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

Authentication policies for Atlassian Government Cloud

An authentication policy allows you set SAML single sign-on for managed accounts, which is a customer responsibility requirement. In an Atlassian Government environment, your authentication policy looks similar to Policy 2 in the illustration above.

From an authentication policy, you see settings for two-step verification, third-party login, and password requirements. However, you are unable to set these options from an authentication policy when you enforce SAML single sign-on. A local directory is also unavailable when you are required to manage all members from your identity provider.

A non-billable policy isn’t available in Atlassian Government environments. This is because don’t have an Atlassian Guard subscription.

複数の認証ポリシー

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

Your organization needs an Atlassian Guard Standardsubscription or be in the Atlassian Government environment to create more than one authentication policy.

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

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

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

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

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

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

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

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

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

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

認証設定のテスト

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

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

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

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