Atlassian アカウントの 2 段階認証を管理する

2 段階認証は、2 番目のログイン ステップを要求することで Atlassian アカウントを保護します。これを使用すると、パスワードが漏洩した場合でもアカウントが保護されます。

2 段階認証の設定

製品インスタンスで強制が有効になっている場合は、管理者としてログインする際に 2 段階認証のセットアップと使用を求められることがあります。

始める前に

2 段階認証の 2 番目のログイン ステップでは、認証アプリから取得する 6 桁の認証コードが必要です。ほとんどの認証アプリがサポートされています。一般的なアプリには、Google AuthenticatorAuthyDuo などがあります。

モバイル デバイスの認証アプリが最も一般的ですが、これは、時間ベースのワンタイムパスワード (TOTP) 認証を提供する唯一のソリューションではありません。ブラウザ拡張機能やハードウェア デバイスのような他の方法もあります。

2 段階認証を設定するのにインターネット接続は必要ありません。エアギャップ インスタンスでもこのメカニズムを採用できます。

2 段階認証の設定

  1. 認証アプリが使用できる状態であることを確認します。

  2. Atlassian アカウントにログインします。[ユーザー プロファイル] に移動し、[2 段階認証] を選択します。

  3. [2 段階認証設定] で、[設定をロック解除] を選択し、パスワードを入力して本人確認を行います。

  4. [認証アプリ] タブで、[セットアップ] を選択し、画面の指示に従います。

2 段階認証を使用したログイン

2 段階認証を有効化すると、ログインに毎回認証アプリが必要になります。

  1. 通常どおりにユーザー名とパスワードを入力します。

  2. 認証アプリを開き、6 桁の認証コードを取得します。

  3. 認証コードを入力して、[ログイン] を選択します。

アカウントの回復

認証アプリにアクセスして認証コードでログインできない場合は、セットアップ中に作成した緊急時のリカバリ キーを使って Atlassian アカウントを復旧してください

確認コードの代わりに緊急リカバリ キーを使用する

アカウントを復旧する方法

  1. 通常どおりにユーザー名とパスワードを入力します。

  2. 認証コードを求める画面が表示されたら、代わりに [モバイル デバイスを使用できない場合] を選択します。

  3. 緊急時のリカバリ キーを入力して、[ログイン] を選択します。

  4. 緊急時のリカバリ キーは一度しか使用できないため、新しい緊急時のリカバリ キーが発行されます。新しい緊急時のリカバリ キーをコピーするか、印刷するか、書き留めてください。

新しい緊急リカバリ キーの作成

緊急時のリカバリ キーを紛失した場合、または他人がアクセスする可能性がある場合は、新しい緊急時のリカバリ キーを作成できます。ただし、まだログインしている場合に限ります。新しい緊急時のリカバリ キーを作成すると、古いキーが置き換えられます。

リカバリ キーを紛失し、すでにログアウトしている場合は、管理者に連絡して Atlassian アカウント再びアクセスできるようにしてください。

新しい緊急時のリカバリ キーの作成

  1. Atlassian アカウントにログインします。[ユーザー プロファイル] に移動し、[2 段階認証] を選択します。

  2. [2 段階認証設定] で、[設定をロック解除] を選択し、認証コードを入力して本人確認を行います。最近本人確認を行った場合は、このステップは必要ありません。

  3. [認証アプリ] タブで、[管理]、[新しいリカバリ キーを作成] の順に選択し、画面の指示に従います。

新しい緊急時のリカバリ キーを必ずコピー、印刷、または書き留めてください。

認証アプリを変更

一度に利用できる認証アプリ接続は 1 つだけです。アカウントを新しい認証アプリに接続すると、前の認証アプリが無効になります。

認証アプリを変更する方法

  1. Atlassian アカウントにログインします。[ユーザー プロファイル] に移動し、[2 段階認証] を選択します。

  2. [2 段階認証設定] で、[設定をロック解除] を選択し、認証コードを入力して本人確認を行います。最近本人確認を行った場合は、このステップは必要ありません。

  3. [認証アプリ] タブで、[管理][認証アプリの変更] の順に選択して、画面に表示される指示に従います。

2 段階認証の無効化

2 段階認証を無効にすると、2 番目のログイン ステップによるアカウントの保護が受けられなくなります。

製品インスタンスで強制が有効になっている場合は、管理者として次回ログインする際に 2 段階認証のセットアップと使用を求められることがあります。

  1. Atlassian アカウントにログインします。[ユーザー プロファイル] に移動し、[2 段階認証] を選択します。
  2. [2 段階認証設定] で、[設定をロック解除] を選択し、認証コードを入力して本人確認を行います。最近本人確認を行った場合は、このステップは必要ありません。
  3. [認証アプリ] タブで、[管理][無効にする] の順に選択して、選択を確定します。

2 段階認証を無効にすると、ログイン時に認証アプリを使用しなくなります。2 段階認証はいつでも再び有功にできます。

2 段階認証の強制

二段階認証の強制は既定では無効になっています。JVMランタイムプロパティ -Datlassian.authentication.2sv.enforcement.enabled=true を使って有効にできます。

強制を有効にすると、管理者 (Confluence の場合) やシステム管理者 (他の Data Center 製品の場合) など、ユーザー作成の権限を持つリスクの高い権限のユーザーは、次回のログイン時に 2 段階認証を設定するよう強制されます。

2 段階認証の強制は、サードパーティのソリューションやカスタム統合と衝突する可能性があります。まず、このオプションをテスト環境で試してください。

強制が有効になったら

製品インスタンスで強制が有効になっている場合は、管理者として次回ログインする際に 2 段階認証のセットアップを求められることがあります。その場合は、上位の管理者から 2 段階認証が必要であることを知らせるメールが届くので、「2 段階認証の有効化」セクションの説明に従って、2 段階認証を有効にする必要があります。

Jira をリカバリ モードで実行している場合、2 段階認証が有効になっていると、ログイン フォームはリカバリ管理者の認証情報を受け付けなくなります。

従来のログイン フォーム

2 段階認証機能を使用するログイン フォームは既定で有効になっていますが、使用する環境で問題がある場合は、従来のログイン フォームに戻すことができます。

従来のログイン フォームは 2 段階認証をサポートしていません。従来のログイン フォームではインスタンスのセキュリティ レベルが低下するため、最後の手段として、または一時的にのみ元に戻してください。

従来のログイン フォームを有効にするには、JVM フラグ -Datlassian.authentication.legacy.mode=true を使用してください。

2 段階認証機能を使用したログイン フォームに問題がある場合は、必ず報告してください。

レート制限保護

レート制限は、ログイン時に時間ベースのワンタイム パスワード (TOTP) とリカバリー コードを検証するサービスに加え、セッション昇格時の TOTP、リカバリー コード、パスワード検証に適用されます。

リクエストが失敗する( ユーザーが間違ったコードを入力する) たびに、ユーザーはバックオフ期間中にそれ以降のリクエストを行うことができなくなります。その期間が終了するまで、行われたすべての検証リクエストでレートが制限され、それ以上処理されません。バックオフ期間が終了した後にリクエストが行われると、通常どおり処理され、提供されたコードが検証されます。コードが正しくないことが判明した場合、バックオフ期間の値は 2 倍になります。バックオフ期間が終了する前に行われたすべてのリクエストは、HTTP 429 エラーで直接拒否されます。

ユーザーがリクエストを実行できなくなるこの期間も、リクエストが失敗するたびに長くなります。この値は 1 秒から始まり、間違った TOTP コードとリカバリー コード (昇格の場合はパスワード) を入力するたびに 2 倍になります。つまり、値は 1 秒から 2 秒、4 秒、8 秒というように指数関数的に増加し続け、3600 秒 (60 分) に達するまで続きます。

既定では、レート制限は最初の連続した試行が失敗した後に適用されます。つまり、ユーザーが 2 回続けて無効な試みをすると、1 秒間ブロックされます。3 回目の試行が失敗するとこれが 2 倍の 2 秒になり、ユーザーは次の 2 秒間検証を試みることができなくなります。

提供されたコードが正しければ、バックオフ期間の値は 1 秒にリセットされます。

許容される失敗回数は atlassian.authentication.2sv.rate.limit.tolerated.failures.count システム プロパティでカスタマイズできます。

バックアップとリストア

インスタンスをバックアップして復元するときは、バックアップが完了していて、データベースとアプリの (共有の) ホーム ディレクトリが含まれていることを確認してください。

復元が不完全だと、安全な処理に必要なデータが失われ、インスタンスの状態が破損したり、実行時に 2 段階認証が機能しなかったりする可能性があります。失われたデータが復元されるまで、インスタンスへの認証がブロックされることがあります。

復旧の登録解除

ユーザーが復旧キーを紛失した場合は、特別な REST エンドポイントを使用して、そのユーザーの 2 段階認証を無効にすることができます。ユーザーが自分で 2 段階認証を無効にできない場合の登録解除オプションとして、システム管理者のみが REST API を介してこのエンドポイントにアクセスできます。セキュリティ上の理由から、システム管理者は TOTP で 2 段階認証を設定する必要があります。

システム管理者は、REST API による 2 段階認証を自分で無効にすることはできません。

URL

rest/tsv/latest/totp/unenroll/user/{otherUserName}

Method

削除

リクエスト

パス:

{otherUserName} - リカバリ キーを紛失し、登録解除が必要なユーザーのユーザー名 (文字列)

ヘッダー:

  • 有効なセッション クッキー (例えば、JSESSIONID)

TOTP コードを指定したボディ:

{ "totpCode": "373416" }

レスポンス

204 - ユーザーは正常に登録解除されました

400 - 指定されたユーザーの登録はありません

{ message: 'No enrollment found for this user.' }

404 - ユーザーが見つかりませんでした

401 - セッション クッキーがないか、TOTP コードが無効です

基本認証

インスタンスの安全性を高めるために、インスタンスの基本認証を無効にすることをお勧めします。2 段階認証ではこの方法は保護されません。基本認証を無効にする方法をご確認ください

統合で基本認証を有効にする必要がある場合でも、基本認証全般を無効にして、例外的なケースに備えて許可リストを準備しておくことができます。基本認証が無効になっているときに許可リストを作成する方法をご確認ください


最終更新日 2024 年 11 月 13 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.