セキュリティプラクティス

アトラシアンのチームについて

ほとんどの企業が同様であると思いますが、私たちは自社のセキュリティ チームを非常に誇りに思っています。業界でも非常に優秀な人材を採用し、チームを編成しています。当社のセキュリティ チームは、サンフランシスコに拠点を置く CISO の指揮の下、シドニー、アムステルダム、バンガロール、オースティン、マウンテンビュー、サンフランシスコ、ニューヨークの各オフィスに、100 人を超えるメンバーが配属されています (一部のリモート チーム メンバーを含む)。セキュリティを優先している Atlassian では、セキュリティ チームは成長を続けています。セキュリティ チームには次のサブ チームがあります。

• 製品セキュリティ – 当社の製品およびプラットフォームのセキュリティを担当
• エコシステム セキュリティ – 当社の Marketplace およびアドオンのセキュリティを担当
• セキュリティ インテリジェンス – セキュリティ インシデントの検出と対応を担当
• レッド チーム – 敵対エミュレーションおよびセキュリティ インテリジェンスの訓練を担当
• セキュリティ アーキテクチャ – 当社の製品およびプラットフォームのセキュリティ要件定義を担当
• 企業セキュリティ – 当社のネットワークおよびアプリケーションに関する内部セキュリティを担当
• トラスト – お客様の期待事項の追跡と対応、および当社のプロセスや実践に関する透明性の提供を担当
• 開発および SRE (Site Reliability Engineering) – セキュリティ チーム用のツールの開発と運用を担当
• 意識向上およびトレーニング – 当社従業員およびパートナーの業務遂行における情報セキュリティ教育を担当

セキュリティ チームは拡大し続けていますが、セキュリティの向上を達成するという Atlassian のミッションを体現するのは、従業員個々人です。この意識は、Atlassian での仕事を通してすべての従業員に浸透しています。私たちは、クラウド セキュリティにおいて業界をリードし、お客様のクラウド セキュリティの要件すべてを満たし、業界のセキュリティ標準と認定の要件をすべて上回り、どのようにお客様のデータを保護しているかに関する詳細情報を公表することを目指しています。当社の目標とビジョンは、Atlassian での仕事を通してすべての従業員に浸透しています。

その他のセキュリティ支援プログラム

基本的なセキュリティ対策を重視する一方、当社ではセキュリティが広く適用されて事前に対応できるように、さまざまなプログラムにも取り組んでいます。プログラムには以下のようなものがあります。

セキュリティ プログラムの継続的な改善

Atlassian では、当社のセキュリティ プログラムが常に業界をリードする最新鋭のものとなるよう、注力しています。そのためには、常に現在のセキュリティに対するアプローチを評価して (同業他社との比較も含め)、改善の機会を捉える必要があります。

この目的に向けて、独立したセキュリティ コンサルティング会社に依頼して、セキュリティ プログラムの成熟度評価を数多く実施してきました (今後も継続して実施します)。また、2020 年には、当社の信頼とセキュリティ プログラムの全体にわたり、相互評価も実施しました。これらのプロセスから抽出した主要な推奨事項などの成果に従い、問題と改善の機会のギャップ解消を図ります。

また、製品セキュリティやセキュリティ インテリジェンスなどのさまざまなセキュリティにおよぶ一連のプログラムも定義し、社内の改善を主導しています。セキュリティ管理チームでレビュー対象とする各プログラムをサポートするため、指標の定義を行いました。これらの指標は、当社の中核的な各機能で、改善すべき領域を特定するために使用します。

詳細情報

このガイドでは、セキュリティに対する Atlassian のアプローチの概要を提供します。セキュリティ プログラムの詳細については、Atlassian Trust Center をご参照ください。セキュリティ プログラムのさまざまな領域ごとに、次の専用の Web ページやホワイトペーパーもご覧いただけます。

• アトラシアンによる顧客データの管理
• 社外セキュリティテストに対する当社のアプローチ
• セキュリティインシデントの管理に対する当社のアプローチ
• アトラシアンの脆弱性管理方法
• クラウド セキュリティの共同責任
• 当社の Atlassian Trust Management System
• アトラシアンのセキュリティ & テクノロジーポリシー

ゼロ トラストによる社内ネットワークへのアクセス保護

アトラシアンでは、企業ネットワーク、社内アプリケーション、およびクラウド環境へのアクセスを、ゼロ トラストと呼ばれる概念によりセキュリティ保護しています。ゼロ トラストの中核的な理念を簡単に言うと、「決して信頼せず、常に検証する」ということです。

ゼロ トラストでは、ユーザー認証のみに依存してネットワーク上のリソースへのアクセス可否を判定するという、従来のネットワーク セキュリティのアプローチを脱却します。このようなアプローチでは、信頼性や安全性が欠けるデバイスにより、セキュリティ侵害がもたらされる恐れがあります。そこで、多くの組織では、モバイル デバイス管理テクノロジーなどのアプローチを使用したり、ネットワーク レベルで既知のデバイスのリストにアクセスを制限したりすることにより、信頼できるデバイスのみが自社ネットワークに接続できるようなモデルへと移行を始めています。

このようなアプローチは便利ですが、きめ細かい対応ができません。ゼロ トラストに対するアトラシアンのアプローチを用いると、当社のネットワーク上のリソースやサービスへのアクセス可否判定に際し、認証情報だけでなく、他のさまざまな要因も考慮して動的にポリシーを決定するしくみを効率的に構築できます。ユーザーのデバイスのセキュリティ ポスチャーに基づき (場所を問わず)、リソース レベルでアクセス可否を判定できるようになります。

簡単に言えば、ゼロ トラストを運用するネットワーク上で、(相対的な重要性と機密性に基づき) リソースに次の 3 つの階層を作成しました。

• オープン階層 – 当社のネットワークへの認証に成功したあらゆる企業ユーザーがこれらのサービスにアクセスできます。
• 低階層 – 認証された企業ユーザーが、(アトラシアンが所有し管理する) 信頼性のある企業デバイスまたは管理された BYOD (アトラシアンの MDM プログラムに登録済みの私有デバイス) から当社ネットワークにアクセスする場合に限り、これらのリソースを使用できます。
• 高階層 – 認証された企業ユーザーが、アトラシアン提供の企業デバイスからアクセスする場合に限り、これらのリソースを使用できます。当社の企業ネットワークからの本番環境サービスへのアクセスは、高階層デバイスおよび SAML 認証を介した場合にのみ可能となります。

当社のシステムおよびサービスへのアクセスを安全に管理

アトラシアンでは、すべてのシステムおよびサービスに対するユーザー アクセスのプロビジョニング (割り当てまたは取り消し) について、プロセスを明確に定めています。確立されたワークフロー (8 時間ごとに同期) で、当社の人事管理システムとアクセス プロビジョニング システムを連携しています。事前定義されたユーザー プロファイルに基づく役割ベースのアクセス コントロールを使用し、スタッフには業務上の役割に適切なアクセス権のみが付与されるようにしています。すべてのユーザー アカウントは、データ、アプリケーション、インフラストラクチャ、またはネットワーク コンポーネントへのアクセス権を取得する前に、管理者の承認を得る必要があります。

ゼロ トラスト アーキテクチャをサポートし、シングル サインオン プラットフォームを介して社内アプリケーションへのアクセスを制御します。当社のアプリケーションにアクセスするには、従業員は 2 要素目の認証の使用を含む、このプラットフォームを経由した認証を行う必要があります。ユーザーは、アトラシアン従業員にプロビジョニングされる U2F (Universal 2nd Factor) キーまたはモバイル アプリケーション認証コードを使用して認証を行う必要があります。SMS や電話によるワン タイム パスワードなどの、セキュリティが不十分な認証方式は廃止しました。このアプローチの採用により、アトラシアンではフィッシング ベースの攻撃や中間者攻撃に対する耐性が高い認証プロセスを確保しています。テキスト メッセージでコードを送信するシステムはいずれも、熟練した攻撃者に侵害される可能性があります。

エンドポイント デバイスのセキュリティ保護

アトラシアンではエンドポイント管理を組み合わせて使用し、エンドポイント全体で、オペレーティング システムや主要アプリケーションに更新やパッチをデプロイします。また、複数のエンドポイント保護ソリューションも実装し、マルウェアなどの脅威から保護しています。

ゼロ トラスト アプローチの一環として、個人用モバイル デバイスを経由して当社の大半のサービスにアクセスしようとするアトラシアン従業員は、モバイル デバイス管理 (MDM) プログラムに登録する必要があります。これにより、当社のネットワークに接続するあらゆるモバイル デバイスが、暗号化、デバイスのロック、マルウェア対策ソフトウェア、および OS バージョンなどの側面をカバーする最低限のセキュリティ要件を確実に満たすようにできます。

MDM プログラムに登録し、コンプライアンスを維持しているすべての対象従業員は、アトラシアンから毎月、参加手当を受け取ります。

デバイスが非準拠と特定された場合、その従業員には非準拠である旨を通知するメールが届きます。従業員には非準拠を修正するために 24 時間の猶予期間が与えられ、猶予期間が経過するとそのデバイスからアクセスできなくなります。

当社システムにおける構成管理

当社では、本番環境に対しソフトウェアのインストール権限を持つのは、一部のエンジニアやアーキテクトに限られます。ほとんどの場合、ソフトウェアのインストールはできません。本番環境では構成管理ツールを使用して、サーバーの構成と変更を管理しています。これらのシステムへの直接の変更は、一貫性を確保するため、構成管理ツールでプッシュされた承認済みの構成により上書きする設定となっています。当社では、標準の Amazon Machine Images (AMI) を採用しており、AMI またはオペレーティング システムに対するすべての変更は、標準の変更管理プロセスで行う必要があります。例外の構成については、追跡およびレポートを行います。また、リソースを分離し、サービスで発生した問題が他のサービスに影響を及ぼさないようにしています。ピア レビュー/グリーン ビルド (PRGB) プロセスも採用し、複数のレビュー担当者が構成管理ツールでプッシュされた構成の変更を承認できるようにしています。すべてのビルドには暗号により署名され、本番環境では署名付きのビルドのみを実行できます。

ログの利用

当社では SIEM プラットフォームを使用して、さまざまなソースからログを集約します。集約したログには監視ルールを適用し、不審なアクティビティがあればフラグを付けます。このようなアラートのトリアージ、詳細な調査、および適切なエスカレーション方法については、当社の内部プロセスで規定しています。ログが読み取り専用となっている各システムから、重要なシステム ログが転送されます。アトラシアンのセキュリティ チームでは、セキュリティ分析プラットフォーム上でアラートを作成し、セキュリティ侵害の兆候を監視します。SRE チームでは、このプラットフォームを使用して、可用性またはパフォーマンスの問題を監視します。ログは、ホット バックアップで 30 日間、コールド バックアップで 365 日間保持されます。

重要なシステム ログは、内部ログ分析システムと侵入検知システムの両方に統合されます。

ログは、当社の全体的なインシデント検出と対応戦略の主要コンポーネントです。詳細については「セキュリティ脅威の特定、防止、および対処方法」で説明しています。

事業継続とディザスタ リカバリの管理

私たちは製品の回復力を重視しています。お客様と同じ製品を社内でも使用しているためです。中断が起こる可能性についても認識しています。そのため、中断に備えて計画を策定するプロセスを組み込むようにし、実際に中断が発生した際には、お客様への影響を最小限に抑えて中断に対処します。当社の事業継続 (BC) およびディザスタ リカバリ (DR) プログラムでは、これらの目的を達成するために実行されるさまざまなアクティビティを取り込んでいます。

BC および DR 計画のアクティビティにリーダー層が参加することで、すべてのチームに対して回復性の説明責任を確実に果たすうえで必要な管理を行えるようになります。当社の BC および DR 計画アクティビティでは、サービスの「目標復旧時間」(RTO) と「目標復旧時点」(RPO) を分析することにより、コスト、メリット、リスク間の適切なバランスを達成するよう努めています。この分析により、それぞれの復旧要件に基づいてサービスをグループ化するシンプルな 4 層システムの構築が可能になりました。このアプローチの詳細は、「アトラシアンによる顧客データの管理」ページでご確認ください。

当社の BC および DR プログラムには、次のアクティビティが含まれます。

1. 冗長性対策を組み込み、回復性要件を満たす。

2. 上記の冗長性対策をテスト、検証する。

3. テスト結果を分析し、BC および DR 対策の改善を継続的に行う。

アトラシアンでは、クラウド サービス プロバイダーから提供されるアベイラビリティ ゾーンやリージョンなどの冗長性機能を最大限に活用できるように、製品を開発しています。

当社では、潜在的な問題を早期に検出するために、さまざまな指標を継続的に監視しています。それらの指標に基づいて、しきい値を超えた場合にはアラートがサイト信頼性エンジニア (SRE) や関連する製品エンジニアリング チームに通知されるよう設定されており、インシデント対応プロセスを通じて迅速なアクションを実行できます。SRE は DR プログラムのギャップを特定する重要な役割も果たしており、リスクおよびコンプライアンス チームと協力してこれらのギャップを埋めます。各チームには DR 推進者も配置され、そのチームに関連するディザスタ リカバリの状況を監督し、管理をサポートします。

DR テストには、関連するプロセスの文書化などの、プロセスとテクノロジーの側面も含まれています。DR テストの頻度は、各サービスの重要度レベルに基づいて算出されます。たとえば、重要なお客様用のシステムの場合、バックアップとリカバリのプロセスを四半期ごとにテストします。当社では、システムに対し、特別なフェイルオーバー テストを手動で実施しています。これらのテストは、複雑でないテーブルトップ シミュレーションの演習から、より複雑なアベイラビリティ ゾーンまたはリージョンのフェイルオーバー テストに至るまで多岐にわたります。テストの複雑さに関わらず、テスト結果を取り込んで文書化したり、改善の余地やギャップがあるか分析して特定したり、特定したギャップを Jira チケットの活用で修復したりするなど、プロセス全体で継続的に改善できるように努めています。

当社では、重要なサービスに関連するリスクを評価するため、ビジネス影響評価 (BIA) を毎年実施しています。これらの BIA の結果は、DR および BC に関する取り組みの戦略推進に役立ちます。その結果、重要なサービスで効果的な DR および BC 計画を作成できます。

サービスの可用性

上記の対策に加え、当社の Statuspage 製品を使用して、サービス可用性の状況をお客様にリアルタイムで公開しています。当社製品で問題が発生した場合、当社で確認できた時点で、お客様にもご確認いただけます。

バックアップ

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

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

Bitbucket では、データは異なる AWS リージョンにレプリケーションされ、各リージョン内で毎日独立したバックアップが作成されます。

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

物理的なセキュリティ

アトラシアンのオフィスにおける物理的なセキュリティ コントロールは、物理的および環境的なセキュリティ ポリシーに基づき、オン プレミスおよびクラウドの環境全体で堅牢な物理的セキュリティが確実に実施されるようにしています。このポリシーでは、安全な作業場所などのエリアをカバーし、任意の場所の IT 機器を保護し、建物やオフィスへのアクセスを適切な人員に限定し、物理的な出入口を監視します。当社の物理的なセキュリティ プラクティスには、勤務時間中の受付の在席、訪問者の登録要件、すべての非公共エリアへのバッジによるアクセスなどが含まれます。また、正面玄関と搬入口などの出入口での業務時間外のアクセスやビデオ録画について、オフィス ビル管理者と連携しています。

パートナーのデータ センターは、最低でも SOC-2 に準拠しています。これらの認定では、物理的および環境的なセキュリティと保護を含む、さまざまなセキュリティ コントロールに取り組んでいます。データ センターへのアクセスは、権限を付与された人員に限られ、生体認証手段によって検証されます。物理的なセキュリティ対策には、常駐の警備員、有線でのビデオ監視、侵入者用の装置、その他の侵入保護措置が含まれます。

データの暗号化

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

Jira Software Cloud、Jira Service Management Cloud、Jira、Bitbucket Cloud、Confluence Cloud、Statuspage、Opsgenie、Trello のお客様データおよび添付資料を保管するサーバーのデータ ドライブは、業界標準のフルディスク AES-256 を使用して保存データを暗号化しています。プラットフォームの最新情報については、Atlassian Trust ロードマップをご覧ください。

キー管理

アトラシアンではキー管理に AWS Key Management Service (KMS) を使用しています。暗号化、復号化、およびキー管理のプロセスが、AWS の既存の内部検証プロセスの一部として、定期的に検査および検証されます。各キーには所有者が割り当てられ、所有者は、適切なレベルのセキュリティ コントロールをキーに設定する役割を果たします。

テナントの分離

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

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

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

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

TCS が提供するコンテキストは、お客様データとのやりとりが発生する際の「レンズ」の役割を果たし、このレンズが常に 1 つの特定のテナントに限定されます。そのため、あるお客様のテナントが別のテナントのデータにアクセスすることも、別のテナントがそのアクションによって別のテナントのサービスに影響を与えることもありません。

クラウド アーキテクチャの詳細については、「クラウド サポート リソース」にも一部記載がありますので、ご覧ください。

お客様データの管理責任を共有

アトラシアンは、提供するアプリケーション、アプリケーションが実行されるシステム、およびそれらのシステムがホストされている環境のセキュリティ、可用性、およびパフォーマンスについて責任を負います。しかし、セキュリティは、特に次の 4 つの項目に関して、アトラシアンとお客様との間の共同責任です。

お客様データへのアクセスの制御

当社ではすべてのお客様データを平等に機密情報として扱い、これを統括する厳重な制限を適用しています。従業員や契約社員に対し、研修プログラム受講時に啓蒙トレーニングを実施して、お客様データの重要性と取り扱いのベスト プラクティスを教育しています。

Atlassian では、許可された社員のみが、アプリケーションに保管されているお客様データへのアクセス権を持ちます。パスフレーズで保護された個別の公開キーを使用して認証を行い、サーバーでの受信トラフィックでは、Atlassian および内部のデータ センターを経由した SSH 接続のみが許可されます。2FA を必要とする追加の認証要求と確認がない限り、アクセスできるのは権限を有するグループに限られます。

当社のグローバル サポート チームは、厳格な認証および権限のコントロールにより、メンテナンスとサポートのプロセスを容易にします。ホストされているアプリケーションやデータへのアクセスは、アプリケーションの健全性の監視、システムまたはアプリケーションのメンテナンス、または当社のサポート システム経由でのお客様からの依頼に基づいて行います。また、お客様には、当社の同意コントロール チェッカーを介して、サポート エンジニアがデータへのアクセスに適切であると明示的に同意するというオプションも提供されています。

お客様データへの許可されていないアクセスや不適切なアクセスは、セキュリティ インシデントとして扱い、当社のインシデント管理プロセスを通じて管理します。このプロセスには、ポリシー侵害があった場合の、影響を受けるお客様への通知も含まれます。

データの保持と削除

当社は、ユーザーからの個人情報の削除依頼に対応できるよう規定を設けています。また、Atlassian アカウントをお持ちのエンド ユーザーが、ご自身で個人情報を削除できるようにしています。お客様がアトラシアンのツールを使用してデータにアクセスし、インポートおよびエクスポートできるように、インポートおよびエクスポート ツールもご用意しています。

お客様のサイトは、お客様の現在のサブスクリプション期間の終了日から 15 日後に非アクティブ化されます。非アクティブ化されたサイトのデータは、お客様の現在のサブスクリプション期間の終了後、15 日間 (評価サイトの場合) または 60 日間 (有料サブスクリプション サイトの場合) 保持されます。Jira の場合、以前に契約していたすべての Jira 製品のサブスクリプションを解除した場合にのみ、データが削除されることにご注意ください。

追加情報については、セキュリティ プラクティスのページまたはデータ ストレージに関する FAQ をご覧ください。