アプリケーション トンネルのセキュリティの概要

このページでは、リクエストを行う際に使用される認証と承認のメカニズムやリクエスト フローの例など、アプリ トンネルを使用する際の Cloud と Data Center の間の接続のセキュリティに関連する主な概念について説明します。

アプリケーション トンネルとは何ですか?

アプリ トンネルは、Jira や Confluence などのアトラシアン クラウド製品から、ネットワーク内にあるオンプレミス製品 (Jira、Confluence、Bitbucket、Bamboo) にリクエストを送信できるようにする通信レイヤーです。要するに、これらは HTTP リクエストをクラウドからサーバーにルーティングする役割を担います。

トラフィックの暗号化

トンネルを通過するトラフィックは、TLS v1.3 を使用して暗号化されます。トンネリングされたアプリ リンク (トンネルでのみ使用されるアプリ リンクの一種) は製品内で HTTP を使用して設定されるものの、トラフィック自体が安全でないわけではありません。

トラフィック ルーティング

アプリ トンネルは、トンネル サーバーと呼ばれる Atlassian Cloud サービスによってオンプレミス製品から確立された安全な WebSocket プロトコルを使用して実装されます。

いずれのアプリ トンネルについても、Atlassian Cloud からパブリック インターネットを介したオンプレミス製品への中断のない回線と見なすことができます。

トンネルの役割は、リクエストをネットワークにルーティングすることのみです。アプリレベルの認証や承認のメカニズムを検証したり変更したりすることはありません。つまり、トンネルを作成するだけでは、クラウドのリクエストをオンプレミス製品で処理するうえで不十分です。

大まかなリクエスト フロー

下図は、クラウドからファイアウォールを介してネットワークに向かい、トンネル クライアント、さらにアプリ サーバーのトンネル コネクタに到達するトンネルの例を示しています (リクエスト フロー全体を示すものではありません)。

クラウドからのリクエストがトンネルを通過すると、製品のアプリ サーバーに設定されているトンネル コネクタに送られます。この時点で、アトラシアンのオンプレミス製品でリクエストが検証され、認証が確認されます。

• リクエストが認証を必要としないリソースに対するものであれば、リクエストが許可され、結果が呼び出し元に返されます。

• リソースが制限されている場合、リクエストはオンプレミス製品によってブロックされます。

認証と承認の方法は、呼び出し元、つまり Atlassian Cloud 製品によって定義されます。現在、リクエストの送信方法としてサポートされているのは、OAuth 1.0a を使用するアプリ リンクを使用する方法だけです。

アプリ リンクを介した通信

トンネルを経由するすべての通信にアトラシアンのアプリ リンクが使用されますが、技術的には他の認証タイプでリクエストを送信することもできます。しかし、現時点ではアプリ リンクのみを使用しています。

アプリ トンネルと接続のセキュリティ

アプリ トンネルを作成すると、セキュリティ キーが生成されて渡されます。次に、それをオンプレミス インスタンスに追加すると、そのインスタンスが接続を確立できるようになります。

セキュリティ キーはランダムなバイト配列です。

• クラウド側: AES で 256 ビットのキーで暗号化して保存されます。

• オンプレミス側: 既定では AES メカニズムで暗号化してデータベースに保存されます。このアルゴリズムは必要に応じて変更できます。

トンネルの設定時にオンプレミス インスタンスにセキュリティ キーを追加すると、各 Data Center ノードのトンネル クライアント アプリによって起動される個別のクライアント プロセスにセキュリティ キーが渡されます。このクライアント プロセスでは、Atlassian Cloud に対する認証にキーが使用されます。

クライアント プロセスが実際に Atlassian Cloud に接続していることを確認する際には、インスタンスの認証局 (CA) チェーンを使用して、tunnel.services.atlassian.com ホスト名の証明書が検証されます。

オンプレミス製品による認証と承認

アプリ トンネルを通過するリクエストの認証や承認がトンネル自体で行われることはありません。トンネルでは次の検証のみが行われます。

• クライアント (セキュリティ キーを使用)

• リクエストの送信元のクラウド組織 (トンネルが属している組織と同じであることを確認)

これは、悪意のある人物によるトンネルのハイジャックを防ぐためです。

リクエストがトンネルを通過すると、オンプレミス製品でそのリクエストの認証と承認が行われます。デプロイ間接続 (クラウドとサーバー) を必要とするすべての機能はトンネリングされたアプリ リンクに依存するため、認証と承認の方法は OAuth 1.0a に基づきます。

このフローでは、OAuth 1.0a は次の目的で使用されます。

• リンクに対するユーザーの同意と承認を得る

• ユーザーに代わってリクエストを行う

すべてのリクエストがユーザー コンテキストで行われ、サービス間認証方法は使用されません。つまり、オンプレミス製品だけでなく、管理者やユーザーも、特定のリソースに対するアクセスと権限を制御できます。オンプレミス製品における権限と制限事項は優先されます。

認証の詳細を含むリクエスト フローの例

クラウドからサーバーへのリクエスト フローの例を見て、認証と承認の仕組みを確認しましょう。

より具体的に言及すると、この例では次のことを前提としています。

• 管理者が Confluence Cloud と Jira Data Center の間のアプリ トンネルとトンネリングされたアプリ リンクを作成したものとします。

• ユーザーが Jira Data Center 内の課題への課題リンクがある Confluence Cloud ページを開くものとします。

• ユーザーはこのアプリ リンクに関連する機能をこれまで使用したことがないものとします。つまり、初めてリソースを表示しようとしています。

上図の説明は次のとおりです。

1. ユーザーは、Confluence Cloud で、Jira Data Center 内の課題にリンクされた Jira 課題マクロを含むページを開きます。

2. Confluence Cloud からトンネル経由で Jira Data Center にバックエンド リクエストが送信されます。Confluence は該当するユーザーに代わってリクエストを送信することを許可されていないため、リクエストはブロックされます。表示しようとしている Jira 課題マクロには、リンクされた課題を表示する権限がないため、認証が必要である旨を示すメッセージが表示されます。

3. ユーザーがメッセージ内の [認証] を選択すると、Jira Data Center にリダイレクトされ、リンクを承認できるようになります。

4. まだ Jira Data Center にログインしていない場合は、ログイン フォームやシングル サインオンなど、いずれかの認証方法を使用してログインする必要があります。

5. ログインすると、ユーザーは Confluence Cloud が自分に代わって Jira Data Center にアクセスすることを許可するよう求められます。

6. 同意したユーザーは再度 Confluence Cloud にリダイレクトされます。この時点で、Confluence Cloud はトンネルを介してリクエスト トークンをアクセス トークンと交換します。

7. ユーザーに代わって課題の詳細を取得するために、Confluence Cloud では今度は認証方法としてアクセス トークンを使用して、トンネル経由で Jira Data Center に別のリクエストを行います。Jira 課題マクロが正しく表示されます。

ユーザーに代わるリソースへのアクセスとそのアクセス権の取り消し

さきほど説明したように、アトラシアンのクラウド製品では、リンクを承認したユーザーに代わってオンプレミス インスタンスのリソースにアクセスします。

通常、リンクされたエンティティを初めて表示するときにすべてのユーザーがリンクを個別に承認する必要があります。管理者はそのようなリンクを事前に承認することはできません。すべてのユーザーはいつでもリンクへのアクセスを取り消すこともできます。

このような承認済みリンクを使用して行われたリクエストは、現在の権限をすべて考慮して、ユーザーのコンテキストで行われます。つまり、クラウド製品ではユーザー自身がアクセスできないリソースにアクセスできなくなります。

セキュリティに関する追加情報

別の組織に属するアプリ トンネルを使用してリクエストを送信できるでしょうか。

いいえ、両方の組織が同じユーザーに属していてもできません。トンネル サーバー内には、このような呼び出しを防ぐ専用の認証メカニズムがあります。

セキュリティに関するその他の質問

アプリケーション トンネルのセキュリティ