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

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

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

Application tunnels are a communication layer that allows you to make requests from Atlassian cloud apps, such as Jira or Confluence, to the Data Center ones that live in your network – Jira, Confluence, Bitbucket, and Bamboo. In short, they’re responsible for routing the HTTP requests from cloud to server.

トラフィックの暗号化

The traffic that goes through the tunnels is encrypted using TLS 1.2+ (with Perfect forward secrecy) or TLS 1.3, following our standard security protocols. The specific protocol used is determined during the TLS handshake, where the server chooses the most secure protocol supported by both client and server. While you might have noticed that the tunneled app links (a type of app links used exclusively by the tunnels) are configured with HTTP inside the cloud app, it doesn't mean the traffic itself isn't secure. For detailed information about our supported protocols and cipher suites, see supported security protocols for Atlassian cloud apps.

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

App tunnels are implemented using secure WebSocket protocols, established from your Data Center product by an Atlassian Cloud service called Tunnel server. The Tunnel client, a component within your Data Center instance, is crucial for this setup. It establishes and maintains the connection, ensuring smooth routing of requests from the cloud to your Data Center instance.

You could view every app tunnel as an uninterrupted line from Atlassian Cloud to your Data Center instance through the public internet. To ensure secure and localized routing, the Tunnel client exclusively directs requests to applications on the same machine, using the loopback address. This setup utilizes the specific port defined during the tunnel's configuration, ensuring that communication remains confined within your server.

The tunnels are only responsible for routing the requests to your network. They don’t verify or alter any application-level authentication or authorization mechanisms. This means that just creating a tunnel isn’t enough for the cloud requests to be processed in your Data Center instance.

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

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

Once the request from cloud passes through the tunnel, it goes to the Tunnel connector configured in the application server for your Data Center instance. At this point, your Atlassian Data Center instance validates the request, checking for authentication:

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

• If the resource is restricted, the request will be blocked by your Data Center instance.

The authentication and authorization methods are defined by the caller – Atlassian cloud apps. Currently, the only supported way for making requests is by using app links, which use OAuth 1.0a.

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

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

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

When you create an app tunnel, we generate a security key and pass it to you. You then add it to your Data Center instance, which allows that instance to establish the connection.

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

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

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

When added to your Data Center instance when configuring the tunnel, the security key is passed to a separate client process that’s started by the Tunnel client app in each of your Data Center nodes. This client process will use the key to authenticate itself with Atlassian Cloud.

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

Authentication and authorization by Data Center instances

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

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

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

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

When a request goes through the tunnel, your Data Center instance is responsible for authenticating and authorizing it. Since all the features that require cross-deployment (cloud and server) connectivity rely on tunneled app links, the authentication and authorization methods are based on OAuth 1.0a.

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

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

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

All requests are made in user context and not by using service to service authentication methods. This means that your Data Center instance, as well as your admins and users, can control access and permissions for certain resources. Permissions and restrictions in your Data Center instances are respected.

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

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

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

• 管理者が 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 課題マクロが正しく表示されます。

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

As explained earlier, Atlassian cloud apps access the resources in your Data Center instance on behalf of the users that authorized the link.

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

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

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

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

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

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

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