Security | Datadog

セキュリティ

Datadog はセキュリティを重視しています。セキュリティに関してご質問がある場合、または
問題が発生した場合は、お問い合わせください。

製品のセキュリティ

Datadog にとって製品のセキュリティは最も重要です。Datadog は、一般的なアジャイル原則に沿ったソフトウェア開発ライフサイクルを採用しています。アジャイルリリースサイクル全体にセキュリティ対策を施すことで、長期リリースサイクルの開発手法より迅速にセキュリティ重視のソフトウェア欠陥を検出して解決することができます。ソフトウェアパッチは継続的なインテグレーションプロセスの一環としてリリースされます。エンドユーザーに影響を与える可能性があるパッチは可能な限り迅速に適用されますが、エンドユーザーへの通知やサービス停止時間を必要とする場合もあります。

Datadog は、継続的なインテグレーションに取り組んでいます。このため、機能的な問題にもセキュリティ上の問題にもすばやく対応できます。変更の内容と時期は、明確に定義された変更管理ポリシーおよび手順によって決定されます。この理念は、DevOps のセキュリティと、Datadog の導入を後押ししてきた開発手法の要です。このため、Datadog がセキュリティの脆弱性や機能的な問題を解決するまでの平均時間は極めて短くなっています。Datadog は、反復的手法によって DevOps の実践を継続的に強化しています。

物理的なセキュリティ

Datadog 本稼働インフラストラクチャーは、クラウドサービスプロバイダー (CSP) 環境でホストされています。Datadog 本稼働サーバーの物理的環境的セキュリティにかかわる管理 (建物、ドアの施錠など) は、それらの CSP によって行われます。「物理的なアクセスは、敷地の境界と建物の入口の両方で専門の警備員によって厳重に管理されています。データセンターのフロアに立ち入るには、許可されたスタッフでも、二要素認証を 2 回以上行う必要があります。」1

企業のセキュリティ

Datadog は、最新のネットワークセキュリティと比べて、物理的境界によるセキュリティの比重が低下していることは認識しています。いったん境界が突破されると、ネットワーク境界によるセキュリティ保証に依存するサービスはすぐに停止します。このため、Datadog は、通常セントラル IdP を使用し、可能な限り二要素認証を利用して、トランスポートレベルでネットワークアクセスセキュリティを要求すると共にユーザーを個別に認証する内部サービスを活用しています。

Datadog では、年に一度、全従業員を対象にセキュリティ意識を高めるトレーニングを実施し、テクニカルな役職はもちろん、それ以外の役職も含めたセキュリティ網を構築しています。その結果、全従業員がカスタマーデータと企業資産の保護を強く意識しています。セキュリティに関するトレーニング資料は役割ごとに作成され、従業員は自身の役割に合ったセキュリティ知識を獲得し、業務に活用しています。


  1. AWS Shared Responsibility Model」を参照してください。 ↩︎

詳細はこちら

Agent の概要

お客様は、ローカルにインストールされた Agent または HTTP API を使用して Datadog サービスにデータを送信できます。Datadog を使用するうえで、必ずしも Datadog Agent を使用しなければならないわけではありませんが、大半のユーザーは Agent を利用しています。

Datadog Agent はオープンソースです。GitHub で Agent v5Agent v6 のソースコードを 参照できます。Agent v6 は Datadog Agent の最新メジャーバージョンです。コア Agent が Golang で全面的に書き換えられたため、Datadog で並行処理を利用できます。Agent v5 では、フォワーダー、コレクター、DogStatsD、スーパーバイザーを 4 つのプロセスとして個別に実行していましたが、Agent v6 ではこれらが 1 つのプロセスになりました。

Agent v6 には、デフォルトでグラフィカルユーザーインターフェイス (GUI) が付属しており、デフォルトの Web ブラウザで起動します。この GUI は、GUI を起動するユーザーが、Agent の構成ファイルを開く権限も含めて、正しいユーザーアクセス許可を持つ場合にのみ起動されます。GUI には、ローカルネットワークインターフェイス (localhost/127.0.0.1) からのみアクセスできます。最後に、GUI は、GUI サーバーとのすべての通信を認証するために使用するトークンを生成して保存するため、ユーザーの cookie を有効にする必要があります。必要に応じて、GUI を完全に無効にすることもできます。

Agent と Datadog のやり取りについては、https://docs.datadoghq.com/agent/ または https://docs.datadoghq.com/api を参照してください。

認証とアクセス管理

エンドユーザーは、IdP、Datadog がサポートしている Security Assertion Markup Language (SAML)、または「Sign-in with Google」OpenID サービスを使用して Datadog にログインできます。これらのサービスは個人の ID を認証すると共に、情報があらかじめ入力されたサインアップフォームを表示するために、名前、Emailアドレスなどの個人識別情報を Datadog と共有するためのオプションを提供しています。Datadog は SAML をサポートしているため、オーガニゼーションは Datadog への認証を制御し、特定のパスワードポリシー、アカウント復元方法、多要素認証技術などを適用することができます。

Datadog API へのすべてのリクエストに認証が必要です。データ書き込みリクエストには、少なくともレポートアクセス権と API キーが必要です。データ読み取りリクエストには、完全なユーザーアクセス権とアプリケーションキーが必要です。これらのキーは、Datadog サービス機能へのアクセスを許可するベアラートークンとなります。

カスタマーデータの保護

認証済みユーザーによって Datadog サービスに送信されたデータは、機密データと見なされます。このデータは、公共ネットワークを介して送信される際には保護され、保存時には暗号化されます。お客様からの要求があった場合などの一部の例外を除き、カスタマーデータの Datadog 本稼働サービス環境外部への転送は許可されません。

Datadog と Datadog ユーザーの間で送信されるすべてのデータは、Transport Layer Security (TLS) および HTTP Strict Transport Security (HSTS) を使用して保護されます。暗号化通信が途切れた場合、Datadog アプリケーションにはアクセスできなくなります。

現在、カスタマーデータは米国にあり、そのほとんどはバージニア州にあります。Datadog は、さまざまなポイントで暗号化を使用して、カスタマーデータと Datadog の機密情報を保護しています。たとえば、Encryption At Rest (AES-256 など)、システムバックアップ時には非対称暗号化 (PGP など)、機密情報 (パスワード、アクセストークン、API キーなど) の保護時には KMS ベースの保護、GPG 暗号化などです。

カスタマーデータへのアクセスは、それをビジネス要件とする機能に制限されます。Datadog は、管理目的のロールと権限に対して複数レイヤーのアクセス制御を実装しています。カスタマーデータを含む環境にアクセスするには、多要素認証 (MFA) を含む一連の認証/承認制御を経る必要があります。Datadog は、カスタマーデータへのアクセスに対して最小権限原則と Need to Know 原則を適用し、これらの環境へのアクセスは、セキュリティの目的で監視され、記録されます。Datadog は、管理資格情報とアクセス機構の整合性と機密性を確保するように制御を行い、ワークステーションにフルディスクの暗号とユニーククレデンシャルを適用しています。

Datadog は、重要なインフラストラクチャーのセキュリティ関連イベントを監視するために、オープンソース技術と商用技術をカスタマイズして実装しています。API の呼び出しやオペレーティングシステムレベルの呼び出しなどのアクティビティデータは、一元的に記録されます。それらの情報は複数のカスタムルールに基づいて試験され、不正な動作や承認されない動作が識別されます。ルールの結果はオーケストレーションプラットフォームに送付され、セキュリティチームに直接アラートを送信する、追加の認証を要求するなどのアクションが自動的にトリガーされます。

詳細はこちら

証明、認証、フレームワーク

Datadog は、EU-U.S. Privacy Shield Framework への準拠を証明しています。また、クラウドセキュリティアライアンス (CSA) の STAR 登録者です。さらに、Datadog は、自社のセキュリティ、プロセス、およびサービスに対して、SOC 2 Type 2 監査を含む主要な独立第三者検証を推進しています。

法令と規制

Datadog のソリューションは、Datadog が提供するサービスに適用されるすべてのデータ保護法令および規制に準拠しています。

Datadog は、2018 年 5 月 25 日の時点で、一般データ保護規則 (GDPR) に準拠しています。Datadog は、データ処理者としての義務を果たすために、その製品、プロセス、および手順の強化に努めています。

GDPR への対応

GDPR は、個人データに関する EU の規制を標準化し、EU 居住者 (データサブジェクト) の権利を拡大すると共に、個人データを構成する要素の定義も拡大しています。GDPR は、データサブジェクトが自身の個人データを制御および削除する権利を拡大し、特殊なカテゴリの個人データの処理を広く禁じています。データサブジェクトの個人データを処理する組織または団体は、GDPR を理解して遵守する必要があります。

GDPR の詳細については、https://www.datadoghq.com/gdpr/ を参照してください。

Datadog による GDPR の遵守

Datadog は、データ処理者 (プロセッサー) としての義務を果たすために、その製品、プロセス、および手順を変更してきました。Datadog が処理する情報に個人データが含まれていることがお客様から通知された場合、Datadog は GDPR の要件と両者間のデータ処理契約の条項に従ってその義務を果たすことができるようにお客様を支援します。この場合、お客様はデータコントローラー (コントローラー) と見なされ、Datadog はプロセッサーまたはサブプロセッサーと見なされます。

サポートプロセス

Datadog は、受け取った Data Subject Access Request (DSAR) に基づくお客様リクエストを受領、確認、および処理するためのオンラインポータルを実装しています。DSAR の結果、お客様は、Datadog がデータサブジェクトの個人データを安全に削除または返却することを要求できます。その機密性を考慮し、Datadog はデータの削除/返却リクエストを個別に処理します。

GDPR に関するご質問またはお問い合わせは、gdpr@datadoghq.com にお送りください。

Safety and Security

To ensure a safe and trustworthy user experience, Datadog builds security into our platform through safe design and proactive monitoring.

Token Safety

Datadog automatically detects if one of your private Datadog API or application keys is accidentally uploaded to a public GitHub repository. If a valid key is detected, you’ll immediately receive an email notification with instructions on how to secure your account.

How it works

Datadog proactively monitors your API and application keys as follows:

  1. We provide GitHub with regex patterns that could potentially match a Datadog API or application key.
  2. GitHub runs those regex patterns against commits and pushes to public repositories. If a match is found, GitHub automatically sends it to Datadog’s validation endpoint to be verified.
  3. If our validation endpoint determines that the candidate token is valid and active, we immediately take the following actions:
    • Automatically notify you via email
    • Display a banner in the Datadog UI on the API Keys and Application Keys pages within your Organization Settings

What is the impact of a leaked key?

A leaked API or application key can have the following consequences:

  • API keys are used to submit data to Datadog. Exposure may result in unintended data being submitted to your organization.
  • Application keys have the same permissions and capabilities as the key creator. Exposure results in a high risk of unauthorized access.

How will I be notified?

In the event of a key leak, Datadog immediately sends an email notification to the key creator/owner:

Leaked key email

By default, the key creator/owner receives the email notification. If the key creator is no longer part of your organization, then the administrators of your organization will be notified.

To notify additional contacts about a key leak, please contact Datadog support. Datadog recommends using a shared mailing list, such as a generic security contact, to receive notifications rather than a specific user.

Additionally, Datadog displays the following warning banner under Organization Settings to alert you to the active leaked key:

Leaked key banner

What should I do if I receive a leaked key notification?

If you receive a leaked key notification, follow these steps as soon as possible to ensure the security of your account.

Password Safety

To protect your account from brute force and password-spraying attacks, Datadog restricts the use of unsafe passwords. Passwords that appear in third-party, non-Datadog data breaches are considered unsafe.

What restrictions apply?

If you try to register a new account using an unsafe password or change your current password to one, Datadog will display the following warning:

Unsafe password warning

Existing accounts with unsafe passwords can continue to log in, but Datadog will alert users via a warning banner in the Personal Settings page:

Unsafe password banner

What should I do if I see an unsafe password warning?

If you see an unsafe password warning, immediately change your password to protect your account from being compromised.

How does Datadog determine that a password is unsafe?

Datadog maintains a database of hashed passwords obtained from third-party, non-Datadog data breaches. When you sign in, a hashed version of your password is checked against this list. This check follows guidelines established by the National Institute of Standards and Technology.

Content Safety

Many of Datadog’s products combine live data, rich Markdown text, and collaborative features that enable users to create meaningful content. As a proactive safety measure, Datadog protects you against potentially harmful links that may be found in user-generated content.

If you try to access a potentially unsafe link, Datadog displays a warning that shows the full URL and gives you the option of continuing to that site or returning to the previous page:

Unsafe link warning

Datadog protects you from harmful links by following this protocol:

  1. Datadog monitors for clicks on external, user-defined links found in a dashboard, notebook, monitor, log, etc.
  2. When a user clicks an external link, the link is rewritten on the fly and checked against our URL Protection Endpoint to determine if it is potentially harmful.
  3. If the link is determined as potentially harmful, Datadog displays a warning with the option to either proceed to the destination or go back.

問題の公表について

Datadog のセキュリティにバグを発見された場合、security@datadoghq.com にご連絡ください。24 時間以内に (通常はさらに早く) 対応いたします。Datadog との通信を暗号化する必要がある場合は、Datadog の PGP キーをダウンロードできます。発見した問題が解決されるまで、問題を公表されないようにお願いいたします。

Program

Datadog hosts its private Bug Bounty Program with HackerOne. If you’re an independent security expert or researcher and believe you’ve discovered a security-related issue on our platform, we appreciate you disclosing the issue to us responsibly and thank you for your time and expertise.

If you are eligible and want to participate in our private Bug Bounty Program, send us an email at bugbounty@datadoghq.com with your HackerOne username or the email you want an invitation for.

You will report the vulnerability directly in the HackerOne platform and all communication after submission will be conducted there. Before submitting an issue, please read our guidelines and scope of the program.

Eligibility

Datadog employees or contractors—current or former—are not eligible to participate in this program. Please read the complete eligibility requirements before joining the program.

Scope

The scope of the Bug Bounty Program includes Datadog’s products, services, and systems. Vulnerabilities found in vendor systems fall outside of this policy’s scope and should be reported directly to the vendor via their own disclosure programs.

The following describes what systems and types of research are covered under this program. Always be careful to verify whose assets you are testing while performing research.

Rules of Engagement

The following is intended to give security researchers clear guidelines for conducting vulnerability discovery activities to limit the potential for company and/or customer data to be at risk:

  • Do add a prefix Bugbounty- to your Datadog org name.
  • Do report a potential security issue immediately.
  • Do NOT attack other users. If you are testing the ability to access another customer’s data, do not iterate randomly. Create another test account or ask for assistance at bugbounty@datadoghq.com.
  • Do NOT attempt Denial of Service (DoS) attacks. If you notice performance interruption or degradation, immediately suspend all testing.
  • Do NOT perform any phishing, spamming, social engineering, or other form of fraud on our employees or customers.
  • Do NOT perform any physical attacks against Datadog’s property (including workstations, office spaces, servers, or networks) or otherwise try to discover risk beyond digital means against Datadog.
  • Do NOT exploit a security issue you discover for any reason other than to validate your finding.
  • Do NOT deface any Datadog-associated publicly available resource for a proof of concept (PoC) which explicitly states the vulnerability. For example, for a subdomain takeover PoC, upload a file with hello world in it.

Out-of-Scope Vulnerabilities

Any of the following (or related) activities will be automatically considered out of scope for the Bug Bounty Program:

Application Vulnerabilities:

  • Clickjacking or UI redressing (on pages with no sensitive actions)
  • Content injection or “HTML injection” unless you can clearly show risk (other than social engineering)
  • Cross-Site Request Forgery (CSRF) on features which are available to anonymous users
  • Low-impact CSRF including, but not limited to, login, logout, and unauthenticated
  • User session duration
  • Username/email enumeration
  • Same-site scripting and Self-XSS
  • Self-exploitation (i.e., password reset links or cookie reuse)
  • Missing flags on non-essential session cookies
  • Missing security-related HTTP headers which do not lead directly to a vulnerability
  • Open redirects on ad/analytics subdomains
  • Presence of autocomplete attribute on web forms
  • Reflected File Download (RFD) attacks

Data Exposure:

  • Banner or version disclosure of server or software
  • Information disclosure that has no practical use for exploitation
  • Descriptive/verbose/unique error pages (without proof of exploitability)
  • Default configuration files which do not disclose sensitive information

Denial of Service:

  • Denial of Service (DoS) attacks
  • Distributed Denial of Service (DDoS) attacks

End of Life (EoL)/ Outdated Software:

  • Any Datadog-developed software that is EoL or no longer supported
  • Client side bugs which do not affect (and/or are exploitable on) the latest version of modern browsers
  • Outdated dependencies without a working PoC

Physical Security:

  • Man-in-the-middle (MITM) attacks or those requiring physical access to the victim’s device
  • Physical or social engineering attacks

Security Best Practices:

  • Missing SSL/TLS best practices
  • Mixed content warnings
  • Missing best practices in Content Security Policy
  • Missing email security best practices (such as incomplete or missing SPF/DKIM/ DMARC) without a proof of exploitability
  • Issues related to networking protocols or industry standards

Miscellaneous:

  • Bugs Datadog is already aware of (or ones previously submitted by another researcher)
  • Pivoting, scanning, exploiting, or exfiltrating data from internal Datadog systems
  • Pervasive issues or vulnerabilities such as heartbleed, meltdown, spectre, or others without a PoC
  • Results of automated tools or scanners without a PoC
  • Theoretical subdomain takeover claims with no supporting evidence
  • Using unreported vulnerabilities to find other bugs
  • Vulnerabilities in community-contributed API and DogStatsD client libraries
  • Public zero-day vulnerabilities that have had an official patch for less than one month will be awarded on a case by case basis.

Disclosure Policy

The Disclosure Policy of Datadog’s private Bug Bounty Program follows HackerOne’s private program disclosure policy and Datadog’s HackerOne program policy. This program is subject to strict confidentiality requirements. You will need consent from Datadog for any disclosure outside of the program. Prior to accepting an invitation to Datadog’s private program, you should carefully review the program policies and the non-disclosure agreements required for participation.