Atlassian Cloud アーキテクチャと運用プラクティス

アトラシアンのクラウド ホスティング アーキテクチャ

クラウド サービス プロバイダーとして AWS (Amazon Web Services) を採用して、世界中の複数のリージョンで高い可用性を備えたデータ センター施設を使用しています。各 AWS リージョンは、AZ (アベイラビリティ ゾーン) として知られる、複数の独立かつ物理的に分離されたデータ センター郡を備えた個別の地理的な場所を指します。

アトラシアンは、AWS のコンピューティング、ストレージ、ネットワーク、データ サービスを活用して、製品とプラットフォーム コンポーネントを構築しています。これによって、AWS が提供するアベイラビリティ ゾーンやリージョンなどの冗長性機能の利用が可能になっています。

可用性ゾーン

各アベイラビリティ ゾーンは他のゾーンの障害から隔離されて、同リージョンにある他の AZ に低コストで低遅延のネットワーク接続を提供できるように設計されています。このマルチゾーンの高可用性は地理的および環境面におけるリスクの防御の第一線であり、AZ の障害があってもマルチ AZ デプロイ環境で実行されるサービスは影響を受けません。

Jira と Confluence は、Amazon RDS (Amazon Relational Database Service) のマルチ AZ デプロイ モードを利用しています。マルチ AZ デプロイでは、Amazon RDS は同リージョンの異なる AZ において同期スタンバイ レプリカをプロビジョニングして維持し、冗長性とフェイルオーバー機能を提供します。AZ フェイルオーバーは自動化されて、通常は 60 〜 120 秒で実施されます。そのため、管理者による介入なしに、データベース オペレーションを可能な限り迅速に再開できます。Opsgenie、Statuspage、Trello、Jira Align も、レプリカとフェイルオーバーの各タイミングにわずかな差異はあるものの、同様のデプロイ戦略を使用しています。

データの場所

Jira と Confluence のデータは、大多数のユーザーのサインアップ時の場所に最も近いリージョンに保管されます。ただし、特定の場所にデータを保存する必要があるお客様もいらっしゃるため、データ レジデンシーを提供しています。現在、米国と EU の各リージョン、オーストラリアでデータ レジデンシーを提供しており、リージョンを追加する予定です。詳細と更新にサインアップするには、データ レジデンシーのページをご参照ください。

Bitbucket のデータは、米国東部の 2 つの異なるアベイラビリティ・ゾーンにあります。

データ バックアップ

アトラシアンでは、包括的なバックアップ プログラムを運用しています。これには、システム リカバリ要件に合わせてバックアップ対策が設計されている社内システムも含まれます。アトラシアンのクラウド製品の、特にお客様とそのアプリケーションのデータについては、広範なバックアップ対策も講じています。Amazon RDS (Relational Database Service) のスナップショット機能によって、RDS インスタンスごとの自動バックアップを毎日作成しています。

Amazon RDS スナップショットは、ポイントインタイム リカバリ (特定時点への復元) をサポートできるよう 30 日間保持され、AES-256 暗号化を使用して暗号化されます。バックアップ データはオフサイトに保存されませんが、特定の AWS リージョン内にある複数のデータ センターにレプリケーションされます。また、四半期ごとにバックアップ テストを実施しています。

Bitbucket の場合、ストレージ・スナップショットはポイントインタイム・リカバリをサポートできるよう 7 日間保持されます。

これらのバックアップは、お客様による大幅な変更の復元には使用されません。これには、スクリプトによって上書きされたフィールド、削除された課題、プロジェクト、サイトなどの変更が含まれます。データの損失を避けるため、定期的なバックアップをお勧めします。ご利用の製品に関するバックアップ作成の詳細については、サポート ドキュメントをご確認ください。

データ センターのセキュリティ

AWS では、データ センターの保護のために複数の認定を取得しています。これらの認定は、物理的および環境的なセキュリティ、システムの可用性、ネットワークと IP バックボーン アクセス、顧客のプロビジョニング、問題管理を目的としています。データ センターへのアクセスは権限を付与された人員に限られて、生体認証手段によって検証されます。物理的なセキュリティ対策には、常駐の警備員、有線のビデオ監視、侵入者用の装置、その他の侵入保護措置が含まれます。

分散型サービス アーキテクチャ

この AWS アーキテクチャによって、アトラシアンのソリューション全体で使用される多数のプラットフォームや製品サービスがホストされています。これには、メディア、アイデンティティ、コマース、エディターなどのエクスペリエンスなど、複数のアトラシアン製品全体で共有されて利用されるプラットフォーム機能のほか、Jira 課題サービスや Confluence アナリティクスなどの製品固有の機能が含まれます。

マルチテナント アーキテクチャ

クラウド インフラストラクチャに加えて、アトラシアンは製品をサポートする共有プラットフォームを備えたマルチテナント マイクロサービス アーキテクチャを構築して運用しています。マルチテナント アーキテクチャでは、クラウド製品の運用に必要なデータベースやコンピューティング インスタンスなど、単一のサービスを複数のお客様に提供します。各シャード (基本的にはコンテナー、下の図 3 参照) には複数のテナントのデータが含まれますが、各テナントのデータは分離されていて他のテナントからアクセスできません。アトラシアンではシングル テナント アーキテクチャを提供しておりませんので、ご注意ください。

テナントのプロビジョニングとライフサイクル

新規のお客様がプロビジョニングされると、一連のイベントによって分散型サービスの連携とデータ ストアのプロビジョニングがトリガーされます。これらのイベントは通常、ライフサイクルの次の 7 つのステップのいずれかにマッピングできます。

1. コマース システムでは当該のお客様に関する最新のメタデータとアクセス制御情報がすぐに更新されて、その後プロビジョニング連携システムで一連のテナントと製品イベントを通じて「プロビジョニングされたリソースの状態」がライセンスの状態と統一されます。

テナント イベント

テナント全体に影響を与えるイベントで、次のいずれかに当てはまります。

• 作成: テナントが作成され、新しいサイトに使用される
• 破棄: テナント全体が削除される

製品イベント

• アクティブ化: ライセンス製品またはサードパーティ アプリのアクティブ化の後
• 非アクティブ化: 特定の製品またはアプリの非アクティブ化後
• 一時停止: 特定の既存製品の一時停止後、所有する特定のサイトへのアクセスを無効にする
• 一時停止解除: 特定の既存製品の一時停止の解除後、所有するサイトへのアクセスを可能にする
• ライセンスの更新: 特定の製品のライセンスのユーザー数およびそのステータス (アクティブ/非アクティブ) に関する情報を含む

2. お客様のサイトを作成して、そのお客様に適した製品セットをアクティブ化します。サイトのコンセプトは、特定のお客様にライセンスされた複数の製品のコンテナーです (例: ＜site-name＞.atlassian.net の Confluence と Jira Software)。

テナントの分離

アトラシアンのクラウド製品をご使用いただく際に、お客様には一般的なクラウド ベースのインフラストラクチャを共有していただいていますが、あるお客様の行動によって他のお客様のデータやサービスが損われることがないように、論理的に分離する対策を講じています。

これを実現するためのアトラシアンのアプローチは、アプリケーションによって異なります。Jira Cloud と Confluence Cloud の場合は、お客様の間の論理的な分離を実現するために「テナント コンテキスト」という概念を使用しています。この概念は両方のアプリケーション コードに実装されて、アトラシアンが構築した「テナント コンテキスト サービス」(TCS) という仕組みで管理されます。この概念によって、次が保証されます。

• それぞれのお客様のデータは、保存中に他のテナントから論理的に分離された状態にある。
• Jira または Confluence によって処理されるリクエストはテナント特有のビューで表示されるため、他のテナントに影響しない。

簡単に言うと、TCS は個々のお客様のテナントの「コンテキスト」を保管することによって機能します。各テナントのコンテキストは TCS によって一元的に格納される一意の ID に関連付けられて、そのテナントに関係する幅広いメタデータが含まれます。メタデータは、テナントが含まれるデータベース、テナントが所有するライセンス、アクセス可能な機能、その他の設定情報などです。お客様が Jira Cloud または Confluence Cloud にアクセスすると、TCS はテナント ID によってそのメタデータを照合します。その後、メタデータはテナントがセッション中にアプリケーション内で実行するあらゆる操作にリンクされます。

アトラシアン エッジ

お客様のデータは、アトラシアンでは「エッジ」と呼ばれる、ソフトウェアの周辺に構築される仮想的な壁によっても保護されています。リクエストを受信すると、最も近いエッジに送信されます。一連の検証を通じて、そのリクエストは許可または拒否されます。

• リクエストは、ユーザーに最も近いアトラシアン エッジに到達します。エッジは ID システムによって、ユーザーのセッションと ID を検証します。
• エッジは TCS 情報のデータに基づいて、製品データの場所を決定します。
• エッジはリクエストをターゲット リージョンに転送して、そのリクエストはコンピューティング ノードに到達します。
• ノードはテナント構成システムによってライセンスやデータベースの場所などの情報を決定して、他のさまざまなデータ ストアやサービス (画像や添付ファイルをホストするメディア プラットフォームなど) を呼び出してリクエストの処理に必要な情報を取得します。
• 元のユーザー リクエストには、他のサービスに対する過去の呼び出しから収集した情報が含まれます。

サービスの認証と承認

アトラシアンのプラットフォームでは、データのアクセスに最小権限を使用します。つまり、すべてのデータはデータの保存、処理、または取得に責任を持つサービスのみに制限されます。たとえば、メディア サービスでは複数のクラウド製品全体で一貫したファイル アップロードやダウンロードをご利用いただけますが、アトラシアンの他のサービスがアクセスできない専用のストレージが設定されています。メディア コンテンツへのアクセスを必要とするサービスは、メディア サービス API と連携する必要があります。その結果、サービス レイヤーでの強力な認証と承認によって、職務の分離やデータに対する最小権限のアクセスも強化されます。

アトラシアンは JSON Web Token (JWT) によってアプリケーションの外部で署名権限を確保しているため、ID システムとテナント コンテキストは信頼できる情報源です。トークンは、承認されている目的以外には使用できません。自分やチームのメンバーがマイクロサービスやシャードを呼び出すと、トークンが ID システムに渡されて検証されます。このプロセスによって、適切なデータの共有前にトークンが最新かつ署名されていることを確認します。これらのマイクロサービスにアクセスするために必要な承認と認証を組み合わせると、サービスがセキュリティ侵害を受けた場合は範囲が限定されます。

しかし、ID システムがセキュリティ侵害を受けることもあります。このリスクを軽減するために、アトラシアンでは 2 つのメカニズムを採用しています。まず、TCS と ID プロキシは高度に複製されます。ほぼすべてのマイクロサービスには TCS サイドカーがあり、認証権限に対して派生するプロキシ サイドカーを使用しているため、これらのサービスは常時何千も実行されています。1 つ以上のサービスに異常な動作が発生した場合は、その動作を迅速に発見してその課題を修正できます。

また、アトラシアンは、製品やプラットフォームに脆弱性が見つかるのを待っているわけではありません。これらの状況を積極的に特定することでお客様への影響を最小限に抑え、多数のセキュリティ プログラムを実行してセキュリティ脅威を特定して検出し、対処しています。

テナント コンテキスト サービス

アトラシアンでは、マイクロサービスへのリクエストには、アクセスを要求している顧客またはテナントに関するメタデータを必ず含むようにしています。これはテナント コンテキスト サービスと呼ばれて、プロビジョニング システムから直接入力されます。リクエストが開始されるとコンテキストが読み取られて、実行しているサービス コードに取り込まれます。このコードによってユーザーを承認します。Jira と Confluence におけるすべてのサービス アクセス、つまりデータ アクセスにはこのテナント コンテキストが必要で、ないとリクエストは拒否されます。

サービスの認証と承認は、アトラシアン サービス認証プロトコル (ASAP) を介して適用されます。明示的な許可リストによって通信できるサービスが判断されて、承認の詳細によって利用可能なコマンドとパスが指定されます。これによって、セキュリティ侵害を受けたサービスの潜在的なラテラル ムーブメントが制限されます。

サービスの認証と承認に加えてエグレスは、一連の専用プロキシによって制御されます。これによって、アプリケーション コードの脆弱性がこれらの制御に影響を与える可能性が取り除かれます。リモートでコードを実行するには、アプリケーション ロジックを変更できるだけでなく、基盤となるホストのセキュリティを侵害して Docker コンテナーの境界を迂回する必要があります。むしろ、アトラシアンのホスト レベルの侵入検出で不一致フラグが設定されます。

これらのプロキシでは、意図されたサービスの動作に基づき、エグレス動作が制限されます。Webhook を発行する必要のない、またはマイクロサービスとの通信を禁止されている他のマイクロサービスと通信する必要のないサービスです。

データ暗号化

アトラシアン クラウド製品のお客様データは、パブリック ネットワーク経由で転送中に TLS 1.2+ と Perfect Forward Secrecy (PFS) の併用によって暗号化されて、不正な開示や変更から保護されます。TLS の実装では、強力な暗号に加えてブラウザーがサポートするキーワード長を使用する必要があります。

Data drives on servers holding customer data and attachments in Jira Software Cloud, Jira Service Management Cloud, Jira, Bitbucket Cloud, Confluence Cloud, Statuspage, Opsgenie, and Trello use full disk, industry-standard AES-256 encryption at rest.

データ転送ネットワークによって転送される PII は、意図された転送先にデータが到達するように設計された、適切なコントロールに従います。アトラシアン内部の暗号技術と暗号化ポリシーでは、アトラシアンの暗号化メカニズムの実装に関する一般原則を定めて、PII の保存とネットワークを介した PII の転送に伴うリスクを軽減します。PII の暗号化に使用される暗号化アルゴリズムのタイプに関しては、アトラシアン内部のデータ・セキュリティと情報のライフサイクル管理に従って、PII の分類レベルを考慮する必要があります。アトラシアンがお客様のデータを収集、共有、使用する方法に関する詳細については、プライバシー・ページをご参照ください。

データ暗号化の追加機能に関する最新状況については、クラウド・ロードマップをご確認ください。

キー管理

アトラシアンでは、キー管理に AWS Key Management Service (KMS) を使用しています。データのプライバシーをさらに強固にするために、KMS はこれらのキーの生成元であると同時にシークレット ストアとなっています。暗号化、復号化、キー管理のプロセスが AWS の既存の内部検証プロセスの一部として、定期的に検査されて検証されます。各キーには所有者が割り当てられて、所有者は適切なレベルのセキュリティ コントロールをキーに設定する役割を果たします。アトラシアンが管理するキーは、関連する役割や雇用状態の変更に応じてローテーションされます。

また、アトラシアンではエンベロープ暗号化も利用しています。AWS にはアトラシアン側からは決して確認できないマスター キーがあり、キーの暗号化や復号化リクエストには適切な AWS ロールと権限が必要です。エンベロープ暗号化によって個別のお客様向けにキーを構築または生成する際は、データ ストアからのタイプの異なるデータには異なるデータ キーを使用します。さらに、他の AWS リージョンにバックアップ データ キーを提供する、内部のアプリケーション レイヤーに対する暗号化アプローチがあります。毎年、キーは自動でローテーションされて、十万を超えるデータ要素に同一のデータ キーは使用されません。

まもなく、アトラシアンは私有キーの利用 (BYOK) による暗号化を提供する予定であり、お客様はクラウド製品のデータを AWS KMS で自社管理キーによって暗号化できるようになります。BYOK によってキーの管理を完全にコントロールして、自身のエンド ユーザーとアトラシアンのシステムの両方のアクセス権をいつでも付与または取り消せます。

AWS KMS は AWS アカウントの AWS CloudTrail と統合して、すべてのキーの使用状況のログを提供できます。このソリューションによって、データベース、ファイル ストレージなどのアプリケーション、さらにアトラシアンの内部キャッシュやイベント キューを通じて、さまざまな層でデータを暗号化できます。プロセス全体を通して、製品のユーザビリティには影響しません。