Close

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

アトラシアンは、すべてのチームにすばらしいことを実現する力があると信じています。私たちのミッションはすべての業界とあらゆる規模のチームの可能性を解き放ち、ソフトウェアの力を通じて人類の進歩を助けることです。

お客様のミッションは私たちのミッションと同じくらい重要であり、情報は私たちのビジネスと生活すべての中心です。お客様の信頼が私たちの行うことの中心にあり、セキュリティが最優先であるのはこのためです。私たちのセキュリティプログラムには透明性があり、安心して製品とサービスをご利用いただけます。

セキュリティに対する当社のアプローチの詳細をお読みいただき、セキュリティを守るためにお客様にできることをご確認ください。

このページの情報は、特に明記しない限り、Atlassian Cloud 製品の Jira、Confluence、Bitbucket に適用されます。

私たちがおこなっていること

当社の Atlassian Trust Management System (ATMS) では、それぞれのお客様のセキュリティ要件を考慮し、当社および当社の環境に独自の一連の要件と取り組みを実現しています。取り組みの詳細は Atlassian Trust サイトで確認できます。ここでは、ISO 27001 および SOC2 の認定報告書をダウンロードまたは要求し、CSA STAR への回答、および Atlassian Trust Management System (ATMS) の詳細も確認することができます。

各領域でのセキュリティ対策

当社では、セキュリティに最終的な到達点はなく、継続して対策を実施すべきものだと考えています。そのため、ソフトウェアおよびサービスのセキュリティ強化を目的として、ソフトウェア開発および内部運用プロセスの改善に継続的に努めています。セキュリティの対策はシンプルな方法であるべきと考え、製品やインフラの基礎構造にセキュリティ対策を組み込んでいます。当社で業務の一環としてセキュリティを確保しているいくつかの方法を以下に紹介します。

アーキテクチャ

アプリケーション、ネットワーク、ビジネスプロセス設計時にはセキュリティを最優先

Atlassian Cloud のセキュリティアーキテクチャは、幅広い業界標準とフレームワークを検討し、内部の脅威モデリングプロセスを考慮して設計されています。柔軟性の要件と、お客様のデータの機密性、完全性、可用性を実現するために効果的な制御の要件とのバランスをとるように設計されています。

アプリケーション

アプリ開発時のセキュリティ、データセキュリティおよび情報のライフサイクル管理。

セキュリティ

暗号化、脅威への対策および脆弱性の管理、セキュリティインシデント管理。

インフラストラクチャ

資産管理、アクセス制御、運用、通信セキュリティ。

データセンターとオフィス

物理および環境面でのセキュリティ。

企業

セキュリティガバナンス、セキュリティ部門、人的セキュリティ、サプライヤーおよびサードパーティでのデータ管理、モバイルセキュリティ、ビジネス継続性、監査/コンプライアンス、プライバシー。

当社のアーキテクチャを実現するセキュリティ制御は異なる複数の標準に準拠するように設計されています。このような標準間の重複を受け、当社では独自の制御フレームワークを構築しています。このフレームワークに従って、当社が準拠している複数の標準の要件を効率的にマッピングした 1 つの表を作成し、それに従っています。以降の表 1 をご参照ください。

標準 主宰組織 統制 分野

ISO27001

IOS (国際標準化機構)

26 要件

6 条項

ISO27002

IOS (国際標準化機構)

114 要件

14 分野

PCI-DSS

PCI (Payment Card Industries)

247 要件

6 分野

CSA CCM

CSA (Cloud Security Alliance)

133 統制

16 分野

SOC2

SOC (Service Organisation Controls)

116 要件

5 原則

SOX 404 (IT)

米国連邦法

22 要件

5 分野

GAPP

AICPA (米国公認会計士協会)

106 要件

10 分野

詳細については、当社の共通統制フレームワークをご覧ください。

 

ネットワーク

スタックを階層ごとに制御し、ネットワークアクセスに階層化アプローチを採用

当社ではインフラストラクチャをゾーン、環境、サービスに分割することで、スタックの階層ごとに制御を実装しています。

ゾーニングには、オフィス、データセンター、プラットフォームネットワークトラフィックの制限などがあります。環境の分離では、本番環境と開発環境との接続を制限します。サービスは明示的な承認を必須とすることで、他のサービスとは認証ホワイトリストを介してやり取りするようにしています。

機密性の高いネットワークへのアクセスについては、仮想プライベートクラウド (VPC) ルーティング、ファイアウォールルール、およびソフトウェア定義ネットワークにより制御しています。接続はすべてデフォルトで暗号化されます。

スタッフが接続するには、機密性の高いネットワークアクセス用のデバイス認証、多要素認証、およびプロキシの使用が必須です。お客様のデータにアクセスするには、明示的なレビューと承認が必須です。

また、企業ネットワークと本番環境用ネットワークの両方に侵入検知および侵入防止システムを実装し、潜在的なセキュリティ問題を特定できるようにしています。

アプリケーション

適切なコントロールで設計するために脅威モデリングを導入

製品の計画および設計段階で、その製品または機能に関連する固有セキュリティリスクを把握するために、脅威モデリングを使用しています。脅威モデリングとは一般に、アプリケーションまたはサービスのエンジニア、セキュリティエンジニア、アーキテクト、およびプロダクトマネージャーの間で行うブレインストーミングセッションです。脅威の特定および優先付けを行い、その情報を設計プロセスで活用し、また開発の後の段階であるレビューやテストの重点管理に使用します。

当社ではマイクロソフト社の Threat Modeling Tool と、脅威モデルフレームワークである STRIDE を使用しています。STRIDE は、セキュリティでの一般的な考慮事項の頭文字を並べたものです (Spoofing: なりすまし、Tampering: 改ざん、Reputation: 否認、Information Disclosure: 情報の漏洩、Denial of Service: DoS 攻撃、Elevation of Privilege: 権限昇格)。

当社ではこのモデリングを以前から頻繁に使用しており、当社が開発する各製品または機能への脅威を軽減するために、関連するセキュリティ構成および制御を確実に設計しています。

信頼性

当社製品の重要性は、お客様によって異なります。お客様との対話から、Jira や Confluence などの製品は主要なビジネスプロセスの一部となっている場合が多いことを確認しています。当社では自社の一連の製品を使用して業務を行っているため、信頼性と復元性の重要性をよく理解しています。

プラットフォーム全体の可用性と冗長性

世界各地で複数のデータセンターを運営

当社では、クラウドアプリケーションのすべてを、AWSNTT などのクラウドホスティングパートナーを活用してホストしています。これらのデータセンターはアプリケーションをホストするために設計および最適化され、複数レベルの冗長性を組み込みで提供し、アプリケーションデータの保管先とは異なるフロントエンドのハードウェアノードで稼働しています。

当社ではお客様のデータとサービスの高可用性を重視しています。標準やプラクティスに従って製品の回復性に焦点を当て、最小限のダウンタイムを実現しています。当社の回復性についてのプラクティスは、SOC2、ISO 27002、および ISO 22301 に基づいています。

Jira、Confluence、Statuspage、Trello、Opsgenie、および Jira Align は、業界をリードするクラウドホスティングプロバイダーである Amazon Web Services (AWS) によってホストされています。これにより、冗長性やフェイルオーバーオプションを全体として備えた最適なパフォーマンスを実現します。現在、米国の東部および西部リージョン、EU、および APAC にわたって、複数のリージョンとアベイラビリティゾーンを維持しています。

Bitbucket データセンターのホスティングパートナーは NTT です。同社はセキュリティと可用性において SOC2 と ISO27001 認定を受けています。また、物理的なセキュリティ、ネットワークおよび IP バックボーンアクセス、顧客プロビジョニング、およびインシデント管理などの面で、当社が要求するレベルを確実に実現しています。

当社が複数のデータセンターとアベイラビリティゾーンを活用して高可用性を実現している方法の詳細については、顧客データ管理のページ、およびクラウドホスティングインフラストラクチャのページをご覧ください。

バックアップ

包括的なバックアッププログラム

アプリケーションデータは、データセンター間でレプリケートされる回復力の高いストレージに保存されます。プラットフォーム全体にわたるレジリエンシー (回復力) に加えて、Atlassian Cloud の機能の一部として包括的なバックアッププログラムを実行しています。ただし、このようなバックアップによるリストアおよびリカバリは、当社の Atlassian Cloud プラットフォームでのみ提供されます。

Atlassian Cloud 向けアプリケーションデータベースのバックアップは以下の頻度で実行されます。自動バックアップは毎日実行され、ポイントインタイムリカバリに備えて 30 日間保持されます。スナップショットおよびバックアップデータはすべて暗号化されます。バックアップデータはオフサイトには保存されず、特定の AWS リージョン内の複数のデータセンターにレプリケートされます。バックアップのテストは四半期ごとに実行されます。詳細はインフラストラクチャのページを参照してください。堅牢なバックアッププログラムの実装方法の詳細は、顧客データ管理のページを参照してください。

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

包括的かつテスト済みの事業継続・ディザスタリカバリ計画

当社ではお客様をないがしろにしないというポリシーを掲げており、当社の環境にてあらゆる中断が発生した際にお客様への影響を最小限に抑えるための、強力な事業継続 (BC) およびディザスタリカバリ (DR) 計画を保持しています。

当社のディザスタリカバリプログラムには、ガバナンス、監視、およびテストを適切なレベルで実現するための少数の主要プラクティスが含まれます。

  1. ガバナンス。DR プログラムを実行するうえで鍵となるのは、リーダーシップの関与です。リーダーシップが関与することで、経営・技術の両チームの責任者が協力してレジリエンス戦略に取り組むことができます。
  2. 監視と保守。DR プログラムの監視および管理時には、ガバナンス、リスク、およびコンプライアンスについて規律的なアプローチを執ります。これにより、DR プログラムの主要なアクティビティを監視、測定、報告、および修復する際に、さらに効果的および効率的な運用を行うことができます。サイト信頼性エンジニアは進行中のディザスタリカバリの打ち合わせに参加し、重要なサービスを実行します。エンジニアは特定された DR のギャップについてリスクおよびコンプライアンスチームと議論を行い、必要に応じて適切な修復レベルに専念します。
  3. テスト。当社では、お客様のデータを確実に保持するための DR ライフサイクルの一環として、および、お客様がデータを利用して高い可用性とパフォーマンスを実現できるように、定期的なテストを実行し、継続的な改善に努めています。
    1. アベイラビリティゾーンで障害が発生した際に最小限のダウンタイムで対応できるように、AWS の複数のアベイラビリティゾーンにわたって複数のレベルで回復性のテストを行っています。
    2. 当社では AWS のリージョン間のデータセンターにわたってデータのバックアップを作成しています。1 つのリージョンに障害が発生した場合、事態の悪化に備えてお客様のデータをセカンダリリージョンで保持します。
    3. 当社では AWS リージョンの障害に備えたテストを行っています。リージョン全体に影響する障害はめったに発生するものではありませんが、サービスのフェイルオーバーやリージョンでの回復性の持続的な改善のために、テストを継続して行っています。
    4. バックアップおよび復元の手順を常に用意し、手順を定期的に確認しています。これにより、データの復元が必要な場合に、経験を積んだサポートスタッフが検証済みの手順を実行して素早く操作を完了することができます。

ガバナンス、監視、およびテストを通じたレジリエンシーの保証に加え、アトラシアンでは DR プログラム全体の継続的な改善を重視しています。当社のディザスタリカバリテストおよび事業継続プログラムの詳細は、顧客データ管理のページを参照してください。

当社では、お客様が必要なデータに必要なときにアクセスできるよう、サービス可用性の状態をリアルタイムで公開しています。

製品セキュリティ

この業界での課題の 1 つに、市場への提供速度を維持しながらセキュアな製品を提供することが挙げられます。当社のゴールは、スピードとセキュリティの最適なバランスを実現することです。当社は業務のほとんどに自社製品を利用しています。製品とお客様のデータを安全に保管するために、幅広いセキュリティ制御を実装しています。

暗号化とキーの管理

転送時の暗号化

Atlassian Cloud 製品およびサービスに保存されるすべての顧客データは、公共ネットワークでの転送時には Transport Layer Security (TLS) 1.2+ を使用して暗号化を行い、許可されていない開示や変更を防ぐために Perfect Forward Secrecy (PFS) を採用しています。TLS の実装では、ブラウザのサポート範囲内で、強力な暗号と鍵長の利用を強制しています。

保存時の暗号化

Jira Software Cloud、Jira Service Desk Cloud、Jira Core Cloud、Confluence Cloud、Statuspage、OpsGenie、Trello 内に顧客データと添付書類を保持するサーバーのデータドライブでは、業界標準のフルディスク型 AES-256 を使用して保存時に暗号化します。Bitbucket では、リポジトリへの保存時の暗号化は現時点では提供されていません。

保存時の暗号化は、特に Jira 課題データ (詳細、コメント、添付書類) または Confluence ページデータ (ページコンテンツ、コメント、添付書類) などの顧客データをディスクに保存する場合に実行します。保存時にデータを暗号化すると、不正なアクセスから保護でき、暗号化キーに対して監査付きアクセスが可能な一定の権限を持つロールおよびサービスからのみデータにアクセスできるようになります。

暗号化キー管理

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

テナントの分離

テナントの分離を行うと、顧客が共通の IT インフラストラクチャを共有している場合でも、あるテナントのアクションが別のテナントのデータまたはサービスを損なうことのないようにテナントを論理的に独立させることができます。

アトラシアンでは、テナントの分離についてのアプローチがアプリケーションによって異なるため、それぞれの違いについては別途ご案内します。時間をかけて本格的なマルチテナント SaaS アプリケーションに進化した Jira および Confluence Cloud の場合、アトラシアンではテナントコンテキストというコンセプトを使用しています。これはアプリケーションコードで実装され、アトラシアンが構築した「テナントコンテキストサービス」(TCS) によって管理されます。このコンセプトにより、

  • 各顧客のデータは確実に他のテナントから論理的に分離され、
  • Jira または Confluence で処理されたリクエストは、他のテナントに影響しないよう「テナント固有」として表示されます。

TCS は Jira および Confluence からは独立していますが、これらの運用には不可欠です。非常に大まかに定義すると、TCS は各顧客のテナントの「コンテキスト」を保管することによって機能します。このコンテキストには、そのテナントに関係する幅広いメタデータ (テナントが含まれるデータベース、テナントが保有するライセンス、利用できる機能、その他の設定情報など) および暗号化された一意の認証情報が含まれます。各テナントのコンテキストは、TCS に一元的に保管された一意の ID と関連付けられます。

顧客が Jira または Confluence Cloud にアクセスすると、TCS はテナント ID を使用してそのメタデータを照合します。その後、メタデータはテナントがセッション中にアプリケーション内で実行するあらゆる操作にリンクされます。重要な点は、TCS によって提供されたコンテキストが、効果的な「レンズ」の役目を果たし、顧客データを使用したあらゆるやり取りはこのレンズを通じて発生することになります。重要な点は、このレンズは常に 1 つの特定のテナントに固有のものとして限定されることです。これにより、ある顧客のテナントが別のテナントのデータにアクセスすることができなくなり、またあるテナントがそのアクションによって別のテナントのサービスに影響を与えることがなくなります。

アトラシアンのクラウドアーキテクチャの詳細についてご確認ください。

製品のセキュリティテスト

内部・外部セキュリティテストプログラムでバグ報奨金制度を実施

当社の製品に対する脆弱性管理のアプローチは、内部および外部のセキュリティテストを含みます。既知の問題は、公開のバグトラッカーで参照できます。

内部テスト

このアプローチは、計画、開発、およびテストフェーズに適用されます。各テストは直前のフェーズでの作業に基づいて進められ、段階的に厳しくなります。当社では、開発とテスト段階の両方で、静的および動的なコード分析アプローチを確立しています。開発フェーズでは、コードスキャンを組み込むことで、機能面でのセキュリティ課題、そして機能面以外の特定可能なセキュリティ課題を取り除いています。

テストフェーズでは、開発とセキュリティエンジニアリングチームの両方が敵対的アプローチをとり、自動および手動のテスト技術を使用して機能を壊せるかどうかを試みます。

当社のセキュリティエンジニアリングチームは、さまざまなセキュリティテストツールを開発して、共通タスクを自動化し、製品チームには専用のツールを提供しています。このようなツールはセキュリティチームにとっては有益であり、開発チームでもこのツールを使用してセキュリティスキャンを自身で行い、出力結果について対策を取ることができます。当社のセキュリティエンジニアリングチームはその分野のエキスパートですが、究極的には、社内の開発者の一人ひとりが自身のコードに責任を持つべきであると考えています。

外部テスト

リリースが本番環境に適用されると、外部テストが行われます。このアプローチは "継続的評価" のコンセプトを基盤としています。単発のペネトレーションテストのみに依存するのではなく、公開のクラウドソースに対するバグ報奨金モデルを使用して、常時使用かつ常時テスト形式のモデルを実践しています。

ユーザーが製品を日常業務で使用していて脆弱性を発見した場合は、弊社にお知らせください。報告されたすべての脆弱性に対して早急に回答いたします (詳細については脆弱性情報レポートを参照)。調査中は問題の起票者と進捗を共有し、いただいたお問い合わせにご対応いたします。

新しいインフラストラクチャアーキテクチャ (例: 当社のクラウド環境)、新製品、基盤となる部分の再構築 (例: マイクロサービスの広範な利用) などの、リスクの高い製品やインフラストラクチャに対しては、専門のセキュリティコンサルタントがペネトレーションテストを行います。

当社のペネトレーションテストに対するアプローチは、非常に焦点を絞ったものとなります。一般に、テストは次のように行われます。

ホワイトボックス: テストをサポートするため、テスターには製品エンジニアから設計ドキュメントや概要書が提供されます。
コード支援: テスト中の予期せぬシステム動作を診断し、潜在的なターゲットを特定するため、テスターには関連するコードベースへのフルアクセス権限が与えられます。
脅威ベース: 特定の脅威のシナリオに焦点を当ててテストを行います (セキュリティ侵害が発生したインスタンスが存在すると想定し、それを開始点としてラテラルムーブメントのテストを実施するなど)。

このような評価を行うにあたって、テスターには幅広い情報が提供されているため、これらのレポートや抜粋は外部には公開されません。このようなシステムや製品の大部分は、当社のバグ報奨金プログラムに含まれ、お客様が求める外部による継続的な追加保証を提供します。当社の製品のセキュリティテストの検証方法についての詳細は、社外セキュリティテストに対するアプローチのページをご覧ください。

製品の脆弱性管理

高品質なソフトウェア構築のための革新的アプローチ

当社では、新機能を素早く安全に提供するために、従来の Quality Assurance (品質保証: QA) 領域とは異なる Quality Assistance* 方式を採用しています。QA の役割を、QA 作業を実際に行うメンバーからファシリテーターに変更し、チーム全体で品質について取り組む意識を共有するようにしています。また、開発者が自身の開発した機能を当社の品質標準に従ってテストする取り組みを進めています。

当社では、製品の脆弱性を減らすことに一貫して取り組んでいますが、開発を行うにあたり、すべての不具合を未然に検出することは不可能であることも承知しています。当社ではバグ報奨金パートナーシップを通じて、時間をかけて脆弱性を発見あるいは悪用する経済的負担を高めることで、悪意の第三者にとってより多くの時間とリソースが必要となり、旨味がなくなることを目的としています。当社の製品の脆弱性管理方法についての詳細は、社外セキュリティテストに対するアプローチのページを参照してください。

*注: Quality Assistance という用語は Cem Kaner が定義したものです。この用語の詳細や当社の全体的な品質プロセスにご興味をお持ちの場合、当社の QA についての一連のブログ投稿をご確認ください。

運用プラクティス

当社では製品のセキュリティと同様に、日次業務を内部で慎重に行うことの重要性を理解しています。"セキュリティの内部構築" のコンセプトは当社の内部プロセスに適用している理念と同じであり、当社のビジネスの遂行方法にも影響します。

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

アプリケーション内に保存されている顧客データへのアクセスを必要最小限に制限

当社の SaaS プラットフォームではすべての顧客データを平等に機密情報として扱い、これを統括する厳重な制限を適用しています。内部の従業員や契約社員に対し、採用研修時に啓蒙トレーニングを実施して、顧客データの重要性とそれらを扱ううえでのベストプラクティスを教育しています。

アトラシアンでは、許可されたアトラシアン社員のみが、アプリケーションに保管されている顧客データへのアクセス権を持ちます。パスフレーズで保護された個別の公開キーを使用して認証を行い、サーバーでの受信トラフィックでは、アトラシアンおよび内部のデータセンターを経由した SSH 接続のみが許可されます。

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

お客様のデータが保管されている当社のデータセンターへの物理的なアクセスは許可された人員にのみ許可され、アクセスは生体認証を使用して検証されます。データセンターの物理的なセキュリティ対策には、常駐の警備員、有線でのビデオ監視、侵入者用の捕獲装置、その他の侵入保護措置が含まれます。

顧客データやメタデータへのアクセス権の統括に関するより広範なポリシーが、当社のプライバシーポリシーに含まれます。

サポートによるアクセス

当社のサポートチームは、オープンなチケットを解決するために必要な場合にのみお客様のデータにアクセス

当社のグローバルサポートチームは、当社のクラウドベースのシステムや、保守およびサポートプロセスに利用するアプリケーションへのアクセス権を持ちます。ホストされているアプリケーションやデータへのアクセスは、アプリケーションの健全性の監視、システムまたはアプリケーションの保守、または当社のサポートシステム経由でのお客様からの依頼のみを目的として行います。

トレーニングと啓蒙

当社のセキュリティトレーニングや啓蒙プログラムは、コンプライアンスの確認事項をチェックするだけのものではなく、企業全体での知識の底上げを図るもの

当社は、すべてのメンバーがセキュリティに対して責任を持つことを前提に啓蒙プログラムを作成しています。このような責任範囲は当社の内部セキュリティポリシープログラムに記載があり、このトレーニングおよび啓蒙プログラムを使用して従業員に責任範囲の周知を行います。

採用候補者や契約社員は当社での業務を開始する前に機密保持契約を結び、その後の採用研修でセキュリティの啓蒙コースを受講します。

"継続的な改善" の実現のため、セキュリティの関連メッセージを全社員向けのメールやブログ投稿で配信しています。これらのメッセージには通常、リアルタイムで関連する事象が記載されます。新しく発見または公開された脅威や、セキュリティプラクティスに従うことの重要性の周知などが例として挙げられます。

セキュリティチャンピオン

セキュリティチーム外のスペシャリストの熱意と知識を積極的に取り入れる

当社では啓蒙プログラムとは別の "セキュリティチャンピオン" プログラムを内部で立ち上げています。このプログラムのねらいは、アトラシアンのすべてのチームがセキュリティを常に意識することです。また、さらに多くの従業員がセキュリティ知識を習得できるよう、所属チームが運用であるか開発であるかにかかわらず、組織を横断したセキュリティの基本知識のトレーニングを行っています。これにより、セキュリティに対する情熱や能力を持った専門家が業務の合間にフィードバックを行い、社内で支援を行うことができます。

変更管理

当社はオープンソース形式の変更管理を実現

従来の変更管理プロセスは、ピラミッド形式の変更管理階層で実装されていました。変更を行う場合、それを承認または却下するための会議で提案を行う必要がありました。当社では、"ピアレビュー、グリーンビルド" 方式を導入しています。コードやインフラストラクチャを変更するたびに、その変更による問題を確認するために 1 人以上の同僚 (ピア) によるレビューが必要です。変更または製品の重要性に基づいてレビューの必要数を増やします。当社では開発チームおよびエンジニアに信頼を置き、それらのメンバーがセキュリティやパフォーマンスの問題を検出して実装前に修正することを想定しています。これに関連して、当社では独自の継続的インテグレーションのためのツールである Bamboo を使用して、メインブランチにマージされた変更が、連携、単体、機能、またはセキュリティテストで問題を発生させないかどうかを確認しています。ビルドおよびテストフェーズで問題が検出されなかった場合、Bamboo に緑色のアイコンが表示され、ビルドプロセスが正常に完了します。問題が検出された場合、Bamboo に赤色のアイコンが表示され、問題の原因となっている変更を特定するためにマージの再検証が行われます。"ピアレビュー、グリーンビルド" 方式により、週に千件単位で実装される変更の中から問題の原因となるものを特定できます。

従業員の雇用

最良の人材の雇用に努める

あらゆる企業と同様に、当社では最良の人材を採用できるように努めています。毎週の全社ミーティングですべての新入社員を紹介し、当社の理念に則って最高の仕事をして、一人ひとりがアトラシアンを良い方向に変えられるよう、意欲をかきたてます。アトラシアンが素晴らしい会社になるには、あらゆる従業員が豊かな能力を日々活かしてくれることが重要であると考えています。採用の過程では、雇用、ビザ、背景、および財務資格の調査を行います。採用の合意がとれたら、各新入社員に対して 90 日間の基礎研修と職種に基づいた研修を行います。

Customer Exit Procedure

If a contract between Atlassian and one of our customers using our cloud products ends, customer data will be removed from our cloud environment according to the timelines below.

Scenarios where customer contract can end include:

  • Missed payments: Where an existing customer misses a payment for their product subscription (whether monthly or annually);
  • Subscription cancellation: Where an existing customer cancels their subscription;
  • Evaluation period ends: Where the trial period for a customer evaluating one of our products chooses not to proceed to a paid subscription.

Missed payments

Where a customer misses a payment or the payment cannot be made, they are unsubscribed from all products 15 days after the due date for the payment. Once this occurs, their data is retained in cold backup for 60 days, after which it is deleted. Customers can ensure their data is not deleted by rectifying any missed payments within the 15 days. It is not possible to restore customer data after this timeline even if payment has been made.

Subscription cancellation

If a customer ends their subscription intentionally, customer data is deleted 60 days after current subscription period ends (for paid sites).

For Jira, if a customer unsubscribes from one Jira product (e.g. Jira Software) and retains another (e.g. Jira Service Desk), their Jira data will be retained. This includes situations involving evaluations; if the evaluation period for one Jira product ends, but the customer still has other Jira products on their subscription, their Jira data is retained. However, if they unsubscribe from all Jira products, their Jira data will be deleted immediately.

Similarly, if a customer removes Confluence from their Atlassian product subscription, this will immediately delete their Confluence data and remove Confluence access for all users.

Evaluation period ends

Where a customer’s evaluation period ends, and they choose not to proceed with a paid subscription, their data is deleted after 15 days (for evaluation sites)

Once customer data is deleted in any of the above scenarios, it cannot be recovered.

Data Destruction

Your data will be deleted 15 days (for evaluation sites) or 60 days (for paid subscription sites) after you have been unsubscribed due to missed payment for an Atlassian product subscription or you cancel your subscription.

What happens if I miss a payment or cancel an individual product subscription?

If payment fails for your Atlassian product subscription, you will be unsubscribed from all products 15 days after the payment due date, at which point users will no longer be able to access the product.

Canceling your Atlassian product subscription will prevent any further site renewals from being processed. Your site will remain accessible until 15 days after the end of your current subscription period, at which point your site will be deactivated. 

Data retention

Your site will be deactivated 15 days after the end of your current subscription period. Atlassian retains data for deactivated sites for 15 days (for evaluation sites) or 60 days (for paid subscription sites) after the end of your current subscription period. 

Evaluations for individual products on an annual Atlassian product subscription last for 30 days. If we fail to receive payment, you will be unsubscribed from Jira and Confluence products 17 days after the payment due date, at which point users will lose access to Jira and Confluence.

Confluence data will be deleted 15 days after the product is unsubscribed. If your evaluation for one Jira product (e.g. Jira Service Desk) ends but you still have other Jira products (e.g. Jira Software) on your annual subscription, your Jira data will not be deleted. Jira data will only be deleted if you unsubscribe from all Jira products. 

Your data cannot be recovered after it's deleted. We strongly recommend creating a Confluence site backup or Jira site backup, as noted below.

How should I prepare my data to move to another site?

セキュリティプロセス

当社では、エラーを完全に防ぐことは不可能であることを理解しています。影響を最小化するため、セキュリティの問題を事前に検出して可能な限り早急に問題を特定できるようにします。

セキュリティインシデント管理

インシデントを完全に防ぐことは難しいですが、素早く効果的な対応を行い影響を最小限に抑えます。

アトラシアンのセキュリティチームはホスティングインフラストラクチャのさまざまなソースからログを収集し、SIEM プラットフォームを使用して不審なアクティビティを監視および検出します。このようなアラートのトリアージ、詳細な調査、および適切なエスカレーションについて、当社の内部プロセスで規定しています。お客様やその他のコミュニティでセキュリティインシデントと疑われる事象を確認した場合は、アトラシアンサポートにご報告ください。

重大なセキュリティインシデントが発生した場合、内外の専門チームを招集して調査を行い、事態の解決まで対応します。当社のセキュリティインシデントのデータベースとして VERIS フレームワークを使用しています。

当社のセキュリティインシデント管理プロセスセキュリティインシデント発生時の共同責任の詳細をご確認ください。

脆弱性管理

当社の環境に存在する可能性がある脆弱性を確実かつ主体的に検出するため、さまざまな脆弱性管理プログラムを導入しています。

前述の製品固有の脆弱性管理とは別に、セキュリティチームは業界をリードする脆弱性検出ツールを使用して、当社の内部および外部のインフラストラクチャに対するネットワーク脆弱性スキャンを継続的に行っています。このプロセスの詳細については、当社の信頼に関する FAQ をご覧ください。

また、当社ではリスクの高い製品やインフラストラクチャについて、セキュリティコンサルティングの専門団体にペネトレーションテストを依頼しています。例としては、新しいインフラストラクチャの立ち上げ (例: 当社の Cloud 環境)、新製品 (例: Stride)、基盤レベルの再構築 (例: マイクロサービスの広範な利用) などが挙げられます。

報告されたあらゆる脆弱性について、内部プロセスを通じてレビューおよび対応を行います。このプロセスには、CVSS のセキュリティレベルに基づいた、脆弱性に対するパッチ提供の SLA が事前に定義されています。詳細についてはセキュリティバグ修正ポリシーをご参照ください。

当社のセキュリティテストについては、社外セキュリティテストに対する当社のアプローチをご覧ください。

当社の脆弱性管理プログラムについては、アトラシアンの脆弱性管理をご覧ください。

バグ報奨金

バグ報奨金プログラムを通してシステムを常にテスト

当社のセキュリティバグ管理へのアプローチの中心的な取り組みとして、バグ報奨金プログラムを通じて製品のセキュリティ面での脆弱性を常にテストしています。リリースが頻繁に行われる真にアジャイルな開発環境では、テストの継続的な実施は必須事項です。当社のバグ報奨金プログラムには、独立したセキュリティ調査者が多数参加しており、もっとも効果的な方法で外部セキュリティテストプロセスを実行し、この目的の達成に貢献します。

当社の製品または環境の数は 25 を超え、Server 製品、モバイルアプリ、Cloud 製品など多岐にわたります。これらのすべてがバグ報奨金プログラムの対象となり、500 人以上のテスターがこのプログラムに登録しています。報告された脆弱性の数、当社の平均応答時間、平均支払金額の詳細については、バグ報奨金プログラムをご覧ください。

当社のセキュリティテストについては、社外セキュリティテストに対する当社のアプローチをご覧ください。

最新テストレポートのダウンロード

以下のレポート内で報告されたセキュリティ上の脆弱性は、バグ報奨金の収集プロセスを通じてアトラシアン内部の Jira で追跡され、セキュリティバグ修正ポリシーの SLA タイムラインに従ってクローズされます。

 

コンプライアンス

当社では、著名なさまざまな業界標準に準拠してセキュリティプログラムを実行しています。各認定を通じて、お客様の求める要件を満たしていることを保証しています。当社のセキュリティ管理プログラムの詳細についてご確認ください。

現在、SOC 2、ISO27001、PCI DSS、および CSA STAR 標準の認定を受けています。これらのプログラムの詳細については、当社のコンプライアンスページをご参照ください。

標準

主宰組織

状況

ISO27001

IOS (国際標準化機構)

当社では認定証明書に記載された事業領域において ISO27001 に準拠しています。セキュリティチームによるセキュリティエンジニアリング、セキュリティインテリジェンス、およびセキュリティプロジェクトの機能が認定の対象です。現在、この認定の範囲を組織全体に拡大しています。

ISO/IEC 27001 では、ISO/IEC 27002 で詳細に規定されている包括的なセキュリティ管理策も活用しています。この認定の基本となるのが、情報セキュリティマネジメントシステム (ISMS) を含む、厳格なセキュリティ管理プログラムの開発と実装です。この国際的なセキュリティ標準は幅広く認知および尊重されており、認定を獲得した企業が次を実行していることを認めています。

  • 情報セキュリティのリスクを体系的に評価し、セキュリティの脅威と脆弱性の影響を考慮
  • セキュリティのリスクに対処するための包括的な情報セキュリティ管理を設計・実装
  • 総合的な監査およびコンプライアンス管理プロセスを実施して、継続的に組織のニーズを満たすような管理を実行

アトラシアンの ISO/IEC 27001 認証を表示

ISO27018

IOS (国際標準化機構)

アトラシアンでは現在、GDPR コンプライアンスプログラムの一環として、業務全体を通じたセキュリティおよびプライバシー制御で ISO 27018 の要件を実現するように取り組んでいます。

ISO/IEC 27018 は、クラウドでの個人データの保護に焦点を当てた実践規範です。これは、情報セキュリティ標準 ISO/IEC 27002 を基盤としており、パブリッククラウド内の PII (個人識別情報) に適用される ISO/IEC 27002 コントロール向けの補足的な実施要項です。また、既存の ISO/IEC 27002 コントロールセットでは対応できないパブリッククラウド内の PII に対する保護要件に対応するための、補足的なコントロールおよび関連のガイダンスも含まれています。

アトラシアンの ISO/IEC 27018 認証を表示

PCI-DSS

Payment Card Industries

アトラシアンはアトラシアン製品の購入において PCI DSS の認定を受けています。ここで指すアトラシアン製品は、お客様のクレジットカードデータの処理や保管を行いません。

アトラシアンの製品やサービスの代金をクレジットカードでお支払いになる場合は、決済処理のセキュリティを適切に保護しているので、安心してご利用いただけます。レベル 2 事業者であるアトラシアンは、認定審査機関 (QSA) と共同で当社の PCI DSS 準拠を評価しています。現在は PCI DSS v3.2SAQ A に準拠しています。

アトラシアンの PCI コンプライアンス認定 (AoC) を表示またはダウンロード:

CSA CCM / STAR

Cloud Security Alliance

アトラシアン向けの CSA STAR Level 1 Questionnaire は、Cloud Security Alliance の STAR Registry ウェブサイトからダウンロードしていただけます。

The CSA Security, Trust & Assurance Registry (STAR) は、無料で一般公開されているレジストリであり、さまざまなクラウドコンピューティングサービスのセキュリティ管理について説明されています。お客様は、このレジストリを参照することで、現在契約している、または新規契約を検討しているクラウドプロバイダーのセキュリティを評価できます。アトラシアンは CSA STAR に登録していると共に、Cloud Security Alliance (CSA) の法人会員でもあり、Cloud Security Alliance (CSA) Consensus Assessments Initiative Questionnaire (CAIQ) にすべて回答しています。最新版の CAIQ は CSA の Cloud Controls Matrix (CCM) v.3.0.1 に準拠しており、クラウドサービスの顧客またはクラウドセキュリティの監査人がクラウドプロバイダーに対して尋ねると想定される 300 以上の質問に対する回答を記載しています。

CSA Star Registry でのアトラシアンの CIAQ エントリを確認

SOC2/SOC3 

Service Organisation Controls

第三者機関によって認定されているアトラシアンの Service Organization Control (SOC) レポートには、コンプライアンスに関する主要な統制と目標をアトラシアンがどのように達成しているのかが明示されています。こうしたレポートの目的は、アトラシアンでの業務運営とコンプライアンスを支援するために確立された統制について、お客様およびお客様の監査役の理解を促すことです。

アトラシアンは多くの製品について SOC2 認定を取得しています。アトラシアンの SOC2 および SOC3 認定をここからダウンロード

また、当社は著名な監査機関を通じ、包括的なセキュリティ監査を年に 1 回以上行っています。

このような監査および認定プログラムの結果と、脆弱性管理などの内部プロセスで得られたすべての情報を、継続的な改善サイクルに取り入れ、セキュリティプログラム全体の改善に活かしています。

GDPR コンプライアンス

アトラシアンは、お客様の成功とデータの保護を何よりも重視しています。この重要な目的を果たす一手段として、アトラシアンでは、お客様とユーザーが GDPR (一般データ保護規則) を理解し、必要な場合は順守する支援をしています。2018 年 5 月 25 日に施行された GDPR は、ヨーロッパのデータプライバシー法制に過去 20 年間で最大の変化をもたらしました。

私たちは、アトラシアンの製品とサービスを使用することによって直接的に関係してくる GDPR 要件が当社のお客様に課されることを十分に理解しています。だからこそ当社は多くのリソースを投入し、お客様が GDPR および各拠点地域の法律の要件を満たすことができるように支援いたします。

当社のクラウド製品の GDPR イニシアチブをいくつか以下に示します。

  • セキュリティインフラストラクチャと認定に多額の投資を実行 (セキュリティと認定のセクションを参照)。
  • Privacy Shield 認定を維持し、最新のデータ処理補遺を通じて標準契約条項を履行することにより、適切な国際データ転送メカニズムを支援。
  • データポータビリティとデータ管理ツールを提供。以下に例を挙げます。
  • お客様の個人データにアクセスし処理を行うアトラシアンのスタッフは、データの取り扱いに関するトレーニングを受けており、データの機密性とセキュリティを必ず確保することを保証。
  • 個人データを扱うすべてのベンダーに対し、当社自身が従っているデータ管理、セキュリティ、およびプライバシーのプラクティスと標準に従うよう求める。
  • 必要に応じて、データ影響評価の実施および EU 規制当局との合議に真摯に取り組む。

当社の GDPR に対するアプローチおよび投資については、アトラシアンの GDPR コンプライアンスのページをご覧ください。

プライバシー

当社ではプライバシーについてのお客様の懸念を理解しています。お客様の懸念は、当社の社員が SaaS ベースのアプリケーションを使用する際の懸念と同等またはそれ以上のものであると考えています。したがって、個人を特定可能な情報やその他の機密データは、当社がサービスプロバイダーに期待するのと同等のレベルで扱うように努めています。

アトラシアンおよびその子会社は、EU-US Privacy Shield Framework、および EU から米国に転送された個人情報の収集、使用、保持に関連する Privacy Shield 原則に準拠します。

プライバシーに対する当社のアプローチの詳細については、当社のプライバシーポリシーをご覧ください。

法的執行要求の取り扱いについて

アトラシアンでは、ユーザーのデータについての法的な要求や、ユーザーアカウントの停止またはユーザーアカウントのコンテンツの削除についての法的な要求について、年に 1 度透明性レポートを公開しています。

共同責任

クラウドにおいて、システム内に保存されるユーザーデータのセキュリティは共同責任で管理されるものとなります。この共同責任については、最近公開したホワイトペーパー『The Atlassian Cloud Security Team (You're part of it)』にて、広範囲にわたって解説しています。

アトラシアンは、アプリケーション自体、アプリケーションが実行されるシステム、およびそれらがホストされる環境のセキュリティに責任を持ちます。PCI-DSS や SOC2 を含む必要な標準にこれらのシステムおよび環境が準拠していることを保証します。

お客様は、アカウント内の情報の管理、アカウントおよび関連する認証情報にアクセス可能なユーザーの管理、および自身でインストールおよび信頼するアプリの制御に関する責任を持ちます。当社のシステムを使用する際に必要なコンプライアンスの要件を満たしているかどうかは、お客様側で確認していただく事になります。

責任のツリー

お客様には次のような点を考慮していただくことをおすすめしております。

重要な決定事項

製品のセキュリティは、その製品のセットアップ時の決定に大きく影響されます。次のような決定事項が重要となります。

  • 全製品 – ドメイン検証および一元管理。1 つ以上のドメインを検証することで、自身の組織がそのドメインを保有していることを証明できます。ドメイン検証を使用することで、組織で全従業員の Atlassian アカウントを管理し、パスワード要件や SAML を含む認証ポリシーを適用することができます。ドメインの検証後、そのドメインに所属する Atlassian アカウントを持つ既存のすべてのユーザーは、自身のアカウントが管理対象アカウントに移行する事を通知するメールを受信します。そのドメインで Atlassian アカウントを新しく登録するユーザーには、それが管理対象アカウントになる事を示すメッセージが表示されます。
  • Bitbucket – リポジトリの公開/非公開。リポジトリを公開するか (インターネット上のあらゆるユーザーがそのリポジトリを参照可能)、非公開にするか (リポジトリへのアクセス権を持つユーザーのみがリポジトリにアクセス可能) を選択できます。
  • Trello – チームおよびボードの公開/非公開。Trello では、ボードを公開する機能を含む、ボードの表示設定を選択できます (Trello アカウントが管理対象である場合は制限があります)。ボードを公開に設定すると、インターネット上のあらゆるユーザーがそれを見ることができ、Google などの検索エンジンでの検索結果に表示されることがあります。Trello のボードの表示設定については、こちらをご覧ください。また、チームを公開して、インターネット上のあらゆるユーザーがチームのプロファイルを閲覧できるようにすることもできます。Trello のチームの表示設定については、こちらをご覧ください。
  • 全製品 – アクセス権の付与。当社ではコラボレーションを実現できるように製品を設計しています。コラボレーションでは、アクセスの許可が必要です。ただし、ほかのユーザーやアプリに自身のデータへのアクセス権限を付与する際には、注意が必要です。権限を付与した場合、対象はその権限に含まれるすべての操作を実行できます。権限に含まれる一部の操作の実行のみを制限することはできません。

ユーザーアクセス

当社の SaaS ソリューションでは、お客様のデータへの適切なユーザーアクセスの責任はお客様自身が持ちます。このため、システムに保存するデータの区分を理解し、データについて許可されたユーザーのみがシステムへのアクセス権を持つようにすることが重要になります。

ロールベースの認証が利用できる場合はそれを利用することで、データ分類への準拠や要件の実現に必要なアクセス制限を簡単に実装できます。

パスワードの運用についてのプラクティスをユーザーと共有することで、パスワード推測や漏えいした認証情報を使用した第三者による不正アクセスなどの脅威を軽減できます。

エコシステム

アトラシアンのエコシステムは、サービスプロバイダであるアトラシアン、お客様およびそれぞれの環境のユーザー、Marketplace で構成されます。お客様は、自身が選択してインストールするアプリを完全に管理できます。インストール時、インストール実行者 (多くの場合はユーザー管理者) はアプリに付与する権限を確認できます。管理者はこの権限に十分な注意を払う必要があります。権限を付与した後に、アプリによる顧客データの使用方法を確認することは困難です。

アプリのインストール前に、アプリの開発者、およびアプリが要求する権限の適合性と正当性を、お客様が確認します。エコシステムの健全性確保のため、アドオンのインストール後はアプリのアクティビティを監視し、不審なアクティビティを見つけた場合は報告することをご検討ください。

詳細情報

このページではさまざまなドキュメントやリソースを案内してきました。セキュリティと信頼に対する当社のアプローチについての詳細は、下記を参照してください。