Data Security Requirements

The following data security requirements correspond to the 2022-23 Data Protection Assessment.

何らかのエラーが発生しました

エラーが発生し、この動画を再生できませんでした。

Apps with access to certain types of Platform Data from Meta are required to complete the annual Data Protection Assessment (DPA). DPA is designed to determine whether developers meet the requirements of Meta Platform Terms as it relates to the use, sharing, and protection of Platform Data. A subset of the DPA questionnaire is focused on Platform Term 6, which outlines data security requirements. We recommend you utilize this document to understand the expectations, requirements, and related evidence with respect to data security use and processing as defined in Meta Platform Terms.

Please note there is a glossary included at the end of this document with key terms and definitions.

Find more video resources from Data Protocol.

Throughout this document, the phrase server side is used as a shorthand for any backend environment that an organization uses to process Platform Data, whether running on a cloud host like Amazon Web Services (AWS), hosted by the developer in a shared or exclusive data center, or a hybrid (combination of these).

Client side requirements refer to processing Platform Data within browsers, mobile devices, within apps on desktop and laptop computers, and other types of devices used by people.

データセキュリティの質問に対する回答の準備

データフロー

アプリまたはシステムでプラットフォームデータがどう処理されるかを示すデータフローの図または説明を作成(または必要に応じて更新)します。

クライアント側 - ブラウザー、モバイルデバイス、サポートされるその他のデバイスタイプなど、すべてのクライアントソフトウェアを含めます。
サーバー側 - 関連するサーバーまたはクラウド環境を含めて、以下を特定します。

プラットフォームデータに対して以下の処理が実行されるコンポーネント:

サーバー環境(例: ウェブリスナー、REST APIなど)への送受信
永続的または耐久性のあるストレージ(データベース、ディスク、ログファイルなど)への書き込み

次のようなホスティングモデル:

自己ホスト型 - 所有または共有のデータセンターにおいて動作している組織所有のサーバー。
Infrastructure as a Service (IaaS) - AWS EC2、Microsoft Azure IaaS、Google Compute Engineなど。
Platform as a Service (PaaS) - AWS Elastic Beanstalk、Google App Engine、Force.comなど。
Backend as a Service (BaaS) - AWS Amplify、Azure Mobile Apps、Firebase、MongoDB Switchなど。
ハイブリッド型 - 上記モデルの組み合わせ。

最後に、データフローの図または説明に以下の内容を含めます。

クライアント/サーバーソフトウェアの両方について、Meta APIアクセストークンが生成され、転送・保管・更新される場所(システム設計において該当する場合)
MetaのAPIからプラットフォームデータ(特に個人の名前、メールアドレス、性別、生年月日、その他のユーザーデータなどの個人を特定できる情報(PII))を取得する方法
上記のデータを使用・保管・転送する方法
プラットフォームデータが送信される第四者

証拠資料の準備

利用者は、実装しているデータセキュリティ保護に関する回答を裏付けるために証拠資料を提出することが必要になる場合があります。この文書にある証拠資料に関するガイドを読み、受け付け可能な証拠資料の例を確認し、それに従って証拠資料を準備することをおすすめします。一般的な形式の文書ファイルのほか、スクリーンショットやスクリーン録画も受け付けます。ファイルがパスワードで保護されていないことを確認してください。複数のファイルをアップロードすることができ、各ファイルの上限は2 GBです。受け付け可能なファイル形式は、.xls、.xlsx、.csv、.doc、.docx、.pdf、.txt、.jpeg、.jpg、.png、.ppt、.pptx、.mov、.mp4、.zip、.zipxです。

送信前に必ず証拠資料から機密性の高いデータを抹消(削除)してください。

証拠資料の種類

データのセキュリティ保護に関する証拠資料のアップロードを求められるアプリの場合、以下の2種類の証拠書類が必要です。

ポリシーまたは手順の証拠資料 - [この保護]に関するデータセキュリティのアプローチについて説明するポリシーまたは手順に関する文書
実装の証拠資料 - 特定の保護をどのように実装しているかを示す、システムまたはアプリケーションから取得した証拠資料(ツール設定やスクリーンキャプチャなど)

ポリシーまたは手順の証拠資料

ポリシーまたは手順の証拠資料(管理コントロールという場合があります)とは、特定のデータセキュリティ保護に関するアプローチについて説明する証拠書類です。この証拠資料の形式は様々です。一連の社内ポリシーからの抜粋や、社内ウィキページの一部あるいは全部でも構いませんし、既存の証拠書類がない場合にはアプローチを説明するために新しく作成した文書でも構いません。いずれの場合でも、アップロードするポリシーまたは手順の証拠資料は、特定の保護に関するアプローチが、Metaの要件とどのように関係するかを明確に説明するものでなければなりません。Metaのセキュリティ審査に必要な関連性のあるポリシーまたは文言のみを提出するか、または質問に関連付けられた自由形式のテキストボックスを使用して、参照すべきセクションを審査担当者に指示してください。

実装の証拠資料

実装の証拠資料とは、ポリシーまたは手順が実際にどのように実装されているかを、スクリーンショットやスクリーン録画により直接例示するものです。開発者が異なれば、設定も異なるため、あらゆるシナリオの例を示すことはできませんが、実装の証拠資料は、弊社ができる範囲で提示した例と同程度の詳細を示している必要があります。

証拠資料の完全性

特定のデータセキュリティ保護の実装を包括的に証明するような実装の証拠資料を準備することは、過度の負担となり得ることがあります。そのことを念頭に置いた上で、ここに記載するガイダンスに従って証拠資料を提出してください。提出する前には、証拠資料から機密性の高い情報を抹消するよう注意してください。

ポリシーまたは手順の証拠資料は、Metaの要件を明確に満たしているか、それ以上のものでなければなりません。

Metaは、特定の保護に関するMetaの要件と一致する記述を確認するために、ポリシーまたは手順の証拠資料を審査します。
文書にマークを入れて、該当するセクションをハイライトしてください。
例えば、プラットフォームデータを送信するすべてのネットワーク接続でTLS 1.2以上の暗号化を有効にするという保護に関する場合、受け付け可能な証拠資料には、以下が明記された文書が含まれます。

Metaからのプラットフォームデータは、信頼されていないネットワーク上で、暗号化されていない形式で決して送信してはならないこと。
プラットフォームデータを受信または返信するすべてのウェブリスナー(インターネット向けロードバランサーなど)は、TLS 1.2が有効にされるように設定すること。
プラットフォームデータを受信または返信するすべてのウェブリスナーは、次のものが無効にされるように設定すること。SSL v2、SSL v3、TLS 1.0、TLS 1.1

実装の証拠資料は、各ポリシーまたは手順の実装例を1つ以上示している必要があります。

各保護がどのように実装されているかを示す文書、スクリーンショットまたはツール設定を1つ以上アップロードする必要があります。
Metaは、実装の証拠資料を審査し、それがポリシーまたは手順の証拠資料と一致していることを確認します。
例えば、プラットフォームデータを送信するすべてのネットワーク接続でTLS 1.2以上の暗号化を有効にするという保護に関する場合、受け付け可能な証拠資料には、ポリシーまたは手順に従って設定されたウェブドメインのいずれか1つに関するQualys SSLテストレポートなどがあります。

証拠資料から抹消すべき機密性の高いデータ

以下のいずれかの値が読み取れる(抹消されていない)形式で含まれている証拠資料は送信しないでください。スクリーンショットに画像加工ツールを使用する場合は、黒塗りのボックスを値の上に重ねてください。PDF編集ツールを使用する場合は、単にテキストを残したままで画像等を重ねるのではなく、実際に値を削除するツール(Appleのプレビューアプリの墨消しツールなど)を使用して必ずテキストを抹消するようにしてください。

健康データ
財務データ
IPアドレス
パスワード、認証情報、アクセストークン
暗号化キー
住所
自然人(会社その他の企業組織を含まない)、従業員、その他の関係者について個人を直接または間接的に特定し得る、以下のような個人を特定できる情報(PII)
- 氏名
- メールアドレス
- ユーザーID
- 生年月日
- 位置情報データ
- 健康データ
- 文化的、社会的、政治的アイデンティティ
- 証拠資料の限られた文脈において、その他の形で個人を特定し得るデータ
脆弱性の詳細な再現手順(侵入テストレポートなど)
13歳未満の児童から取得したデータ、または当該児童に関するデータであることを開発者が知っているか、または合理的に知ることができるデータ

保存データの暗号化を用いて、サーバーサイドで保存されたプラットフォームデータを保護する

質問: クラウド、サーバー、データセンター環境で保存中のプラットフォームデータすべてに対して、保存データの暗号化を実施していますか。

意図

保存データの暗号化により、別の復号鍵がなければデータを解読できないようにすることでプラットフォームデータを保護します。これにより、不正な読み取りアクセスに対する別の保護レイヤーが提供されます。

アプリのすべてのユーザーに関するプラットフォームデータが集中する傾向があるサーバー上またはクラウド環境内では、保存データの暗号化によってデータ漏えいのリスクが軽減されます。
たとえば、保存データの暗号化により、本番環境データベース自体ほどは厳重に防御できない可能性がある、データベースのバックアップに対する不正アクセスなどの脅威を防御します。

要件の概要

プラットフォームデータをサーバーサイドで保存する場合:

以下のいずれかの方法でプラットフォームデータを保護しなければなりません。
- 保存データの暗号化
- 許容される代替的なセキュリティ保護(許容される代替的なセキュリティ保護を参照)

使用する暗号化の種類に固有の要件:
- アプリケーションレベルの暗号化(データベース内の特定の列のソフトウェアによる暗号化/復号化など)またはフルディスク暗号化が認められます。
- 業界標準の暗号化(AES、BitLocker、Blowfish、TDES、RSAなど)の使用を推奨しますが、特定のアルゴリズムや鍵の長さについて要求することはしません。

開発者がサーバーサイドでプラットフォームデータを保存していない場合、本要件は適用されません。

特別なケース

IaaS、セルフホスティング、ハイブリッドホスティングを利用したサーバーサイドでの保存

IaaSホスティング(AWS EC2、Microsoft Azure IaaS、Google Compute Engineなど)、セルフホスティング、またはハイブリッドアプローチを利用してプラットフォームデータを保存している場合には、この質問の対象です。

SaaS、PaaS、BaaS製品を利用したサーバーサイドでの保存

ただし、バックエンドホスティングのモデルには例外があります。

以下いずれかを介してのみプラットフォームデータを保存している(かつ、IaaS、セルフホスティング、ハイブリッドホスティングを利用していない)場合、この質問は適用されません。代わりに、この関係をデータ保護評価のサービスプロバイダーセクションを記入する必要があります。

BaaS - AWS Amplify、Azure Mobile Apps、Azure Playfab、Google Firebase、MongoDB Switchなど
PaaS - AWS Elastic Beanstalk、Google App Engine、Force.comなど
SaaS - MailChimp、Salesforceなど

Meta APIを利用したサーバーサイドでの保存

Instant Games SDKでMeta API (例えば、player.setDataAsync())を介してのみプラットフォームデータを保存している場合、この質問は適用されません。

証拠資料に関するガイド

この保護に関して証拠資料を提出するよう求められる場合には、証拠資料の準備に記載された説明に従って、ポリシー/手順書、および実装の証拠資料の両方を準備してください。

実装の証拠資料の例

AWS RDS

AWS RDS - AWS RDSでは保存データの暗号化が設定可能なため、開発者は、この保護を適用するよう設定オプションがセットされていることを確認しなければなりません。

プラットフォームデータを含む典型的なRDSインスタンスについては、AWS CLIツールを用いて、そのStorageEncryptedの設定を取得してください。

# List RDS instances in default region
$ aws rds describe-db-instances \
  --query 'DBInstances[*].DBInstanceIdentifier'

[
    "database-1",
    "database-2"
]

# For each instance returned, retrieve the storage encrypted config
$ aws rds describe-db-instances \
  --db-instance-identifier database-1 \
  --query 'DBInstances[*].StorageEncrypted'
[
    true
]

$ aws rds describe-db-instances \
  --db-instance-identifier database-2 \
  --query 'DBInstances[*].StorageEncrypted'
[
    true
]

AWS DynamoDB

AWS DynamoDBではデフォルトで保存データの暗号化が行われています。これらのコマンドを用いて、テーブルの保存データの暗号化の設定を取得することができます。

$ aws dynamodb list-tables --output table

--------------
| ListTables |
+------------+
||TableNames||
|+----------+|
||  Users   ||
|+----------+|


$ aws dynamodb describe-table \
 --table-name Users \
 --query "Table.SSEDescription.Status"

"ENABLED"

AWS DocumentDB

AWS DocumentDBで保存データの暗号化を適用するには、設定をする必要があります。プラットフォームデータを含む典型的なクラスターについては、これらのコマンドを用いてStorageEncryptedの設定を取得してください。

$ aws docdb describe-db-clusters --query 'DBClusters[*].DBClusterIdentifier'

[
    "docdb-users"
]

$ aws docdb describe-db-clusters \
  --db-cluster-identifier 'docdb-users' \
  --query 'DBClusters[*].StorageEncrypted'
[
    true
]

AWS S3

AWS S3のバケットでは、バケット内で作成されるすべてのオブジェクトに保存データの暗号化を適用するよう設定することができます。これらのコマンドを用いて、バケットをリストにし、デフォルトでのバケット暗号化の設定を取得してください。

$ aws s3api list-buckets --output table --query "Buckets[*].Name"

---------------------------------------------
|                ListBuckets                |
+-------------------------------------------+
|  platform.storage                         |
+-------------------------------------------+

$ aws s3api get-bucket-encryption \
  --bucket  platform.storage \
  --query "ServerSideEncryptionConfiguration.Rules[*].ApplyServerSideEncryptionByDefault" \
  --output table
---------------------
|GetBucketEncryption|
+-------------------+
|   SSEAlgorithm    |
+-------------------+
|  AES256           |
+-------------------+

Microsoft Azure

Azureでの保存データの暗号化に関するMicrosoftのドキュメントで、組織のサービス利用に関連する記載を参考にしてください。

Google Cloud Platform

Google Cloud Platformでの保存データの暗号化に関するGoogleのドキュメントを参考にしてください。

許容される代替的なセキュリティ保護

サーバーサイドの環境で保存データの暗号化を実施しない場合には、許容される代替方法によりプラットフォームを保護することができます。この場合、以下の内容を記載する必要があります。

プラットフォームデータの機密性 - 特定のプラットフォームデータの保存については、リスクが低い、または高いと判断されます。サーバーサイドに保存されているプラットフォームデータのユーザー属性を具体的に調査する必要があります。
特定の危害が生じる可能性を減らすために適用する制御手段

プラットフォームデータを含むネットワークのセキュリティ侵害を防ぐための制御手段
プラットフォームデータにアクセスできるアプリまたはシステムのセキュリティ侵害を防ぐための制御手段
プラットフォームデータを含む物理的なストレージ媒体(使用されていないネットワークストレージデバイスなど)の喪失を防ぐための制御手段
プラットフォームデータを含む物理的なストレージ媒体(使用されていないネットワークストレージデバイスなど)の喪失を防ぐための制御手段
プラットフォームデータのバックアップを含む、ストレージのバックアップコピーへの不正アクセスを防ぐための制御手段

証拠資料の確実性 - SOC2の監査の一環で行われる評価など、独立した監査人がこれらの保護を評価しているかどうかを示してください。

組織のデバイスとリムーバブルメディアに保存されたプラットフォームデータを損失から保護する

質問:特に組織や個人のデバイスに保存されたプラットフォームデータに関する問題: これらのデバイスに保存されたすべてのプラットフォームデータに関して、保存データの暗号化を実施していますか？またはデータの損失のリスクを軽減するためにポリシーやルールを設けていますか?

趣旨

開発者が社員のノートパソコンやリムーバブルストレージ(USBデバイスなど)にプラットフォームデータを保存することを許可している場合、デバイスが紛失したり盗まれたりしたときに、そのデータは不正にアクセスされるリスクが高くなります。開発者は、このリスクを制限するための手段を講じる必要があります。

要件の概要

プラットフォームデータへの不正なアクセスのリスクを軽減するために、開発者は、組織のデバイス(ノートパソコンなど)とリムーバブルメディア上のプラットフォームデータに関連する技術的コントロール(推奨)または管理コントロール(推奨されないが認められる)を行う必要があります。
- 技術的コントロール - 技術的コントロールの例は以下のとおりです。1)管理対象デバイスのみが企業ネットワークに接続することを許可する、2)管理対象デバイスに完全なディスク暗号化を実施する(BitLockerなど)、3)リムーバブルメディア(USBドライブなど)が管理対象デバイスに接続することをブロックする、4)管理対象デバイスに情報漏洩対策(DLP)技術を使用する。
- 管理コントロール - 管理コントロールの例には、組織や個人のデバイス上のプラットフォームデータを取り扱う上で許容される方法に関する書面のポリシー文書や毎年実施されるトレーニングなどがあります。

この要件は、プラットフォームデータをサーバー側で処理するか否かを問わず適用されます。

証拠資料に関するガイド

この保護の根拠を提出するよう求められた場合は、証拠の準備の説明に従って、ポリシー/手順と実装証拠の両方を準備します。

a)技術的コントロール(ディスクの暗号化など)、またはb)ノートパソコンや携帯電話などの組織のデバイスに保存されているプラットフォームデータのデータ損失のリスクを軽減するためにポリシーやルールのどちらかまたは両方を設けている場合があります。

技術的コントロールには、以下が含まれる場合があります。

管理対象外デバイスが機密サービス(本番ネットワークなど)に接続するのをブロックする
管理対象デバイスでディスク暗号化を(WindowsのBitLockerやMacのFileVaultなどを介して)実施する
管理対象デバイスでのリムーバブルメディア(USBドライブなど)の使用をブロックする
管理対象デバイスでDLPソフトウェアを使用して、プラットフォームデータの不適切な取り扱い(メールの添付ファイルとして送信するなど)をブロックする

ポリシー/ルールには、以下が含まれる場合があります。

一般的なデータ(特にプラットフォームデータ)を取り扱う上で認められる方法と認められない方法を説明するドキュメント
組織のメンバーにガイドラインを意識させるメカニズム(雇用の条件としての契約上の合意、トレーニング、メールを介した定期的なリマインダーなど)

証拠資料の例

組織が、データ分類の基準に従ってMetaのプラットフォームデータを「プライベートデータ」として分類します。この組織は、データの取り扱いに関するガイドラインを策定しており、これらのポリシーを理解して従うことをすべての人員に義務付けています。

暗号化した状態でネットワークを介して送信したプラットフォームデータを保護する

質問: プラットフォームデータが送信されるパブリックネットワークを通過、横断、またはこれに接続するすべてのネットワーク接続に対してTLS 1.2以上のセキュリティプロトコルを有効にしていますか？また、暗号化されていないプラットフォームデータの(HTTPやFTPなどを介した)パブリックネットワークでの送信禁止や、SSL v2、SSL v3のセキュリティプロトコルの使用禁止を徹底していますか？

趣旨

インターネットを横断して転送されるプラットフォームデータには、ネットワークトラフィックを観察できる誰もがアクセスできます。したがって、このようなデータは暗号化によって保護し、不正な人物がデータを読み取ることができないようにする必要があります。

送信中のデータを暗号化することにより、元のデバイスや送信先のデバイスを除いて解読不能にすることで、信頼できないネットワーク(インターネットなど)を経由して送信されるプラットフォームデータを保護します。
つまり、送信の途中に存在する人物がネットワークトラフィックを観察できる場合でも(中間者攻撃攻撃とも呼ばれます)、プラットフォームデータを読み取ることができません。
TLSは、ブラウザーが銀行などのウェブサイトとの通信の安全を確保するために使用するテクノロジーであるため、送信中のデータを暗号化するための最も一般的な形式です。

要件の概要

プラットフォームデータをサーバーサイドで処理するかどうか:

プラットフォームデータは、信頼されていないネットワーク上で、暗号化されていない形式で決して送信してはなりません。
プラットフォームデータを受信または返信するすべてのウェブリスナー(インターネット向けロードバランサーなど)について、以下を行う必要があります。
- TLS 1.2以上を有効にする
- SSL v2とSSL v3を無効にする
TLS 1.0 と TLS 1.1 は、TLS 1.2+に対応していないクライアントデバイスとの互換性を確保するためにのみ使用できます。
Metaでは、完全にプライベートネットワーク内(バーチャルプライベートクラウド(VPC)内など)にあるプラットフォームデータの送信に暗号化を適用することを推奨しますが、これは必須ではありません。

下の表は、さまざまな送信タイプに対する送信時の暗号化ポリシーをまとめたものです。

送信のタイプ	送信時の暗号化ポリシー
エンドユーザーのデバイス(携帯電話、PC、タブレットなど)、サーバー、またはクラウドインフラとのデータのやり取り	互換性のあるデバイスに対してTLS 1.2以上を有効にする必要があります古いデバイスとの互換性のためにTLS 1.0および1.1を有効にすることができます
サーバーまたはクラウドインフラおよび任意のリモートサーバー、または第四者のサービスとのデータのやり取り	TLS 1.2以上を実施する必要があります
全体的にプライベートデータセンター、サーバー、またはクラウドインフラ内にあるコンポーネントとのデータのやり取り	全体的にプライベートクラウドネットワーク内で行われるプラットフォームデータの送信には、TLS暗号化が推奨されますが、必須ではありません
Meta、デバイス、サーバー、またはクラウドインフラとのデータのやり取り	データ保護評価の範囲外 - Metaがこれらの送信のTLSポリシーを管理します

証拠資料に関するガイド

このセキュリティ保護の根拠を提出するよう求められた場合は、証拠資料の準備の説明に従って、ポリシー/手順と実装証拠の両方を準備してください。ウェブリスナーの1つの設定を証明する実装証拠を作成する簡単な方法の1つは、Qualys SSLサーバーテストツールを使用する方法です。

完全に同じ方法で設定された1つ以上のウェブリスナー(非標準ポート上で動作するものを含む)に対してQualys SSLサーバーテストツールを実行します。
[Do not show the results on the boards]オプションにチェックを付けて、結果がQualysのウェブサイトに追加されないようにします。テスト結果全体をPDFで印刷します。プラットフォームデータをやり取りしたウェブリスナーのうちTLS設定が異なるものすべてに対して上記の手順を繰り返します。

実装の証拠資料の例

これは、Qualys SSLサーバーテストツールの出力の例です。どのSSL/TLSバージョンがサポートされているかをまとめた[Configuration]セクション内の赤色の注釈に注目してください。注: この例には、最初の2ページしか含まれていませんが、完全なテスト結果を含める必要があります。

許容される代替的なセキュリティ保護

TLS以外の異なるタイプの暗号化を使用して送信時のプラットフォームデータを保護している可能性がありますが、そのアプローチで同等の保護が実現されていれば、そのアプローチも認められます。この場合、使用されている暗号化に関する詳細を提出し、Metaによる審査を受ける必要があります。

対称的暗号化と非対称的暗号化のどちらか？
暗号化アルゴリズム(AES、BitLocker、TDES、RSAなど)は何か？
最小の鍵の長さはくれくらいか？

アプリとシステムの脆弱性とセキュリティ問題に関するテスト

質問: アプリとシステムの脆弱性とセキュリティ問題に関するテストを少なくとも12か月ごとに実施していますか？(たとえば、手動で侵入テストを実施していますか？)

趣旨

開発者は、脆弱性とセキュリティ問題についてテストして、これらを事前に発見できるようにし、セキュリティインシデントが発生する前に防御することが理想的です。

Metaのプラットフォームを使用して、自身が設定および運用するアプリ/システムを介して、自身が作成したソフトウェアでプラットフォームデータを処理するアプリ開発者
ソフトウェアおよびシステム構成には、悪意のあるハッカーが悪用できるセキュリティの脆弱性が含まれている可能性があり、プラットフォームデータへの不正なアクセスにつながります。

要件の概要

すべての開発者に該当する事項:

開発者は、次のいずれかの方法により、プラットフォームデータの処理に使用するソフトウェアをテストしてセキュリティの脆弱性の有無を確認しておく必要があります。
- アプリ/システムの侵入テスト、または
- ソフトウェアの脆弱性スキャン/静的解析
テストの結果では、未解決の重大な脆弱性または深刻度の高い脆弱性がないことが示される必要があります。
テストは、過去12か月以内に完了している必要があります。

プラットフォームデータをサーバーサイドで処理する開発者に対するその他の要件:

開発者は特に、以下のいずれかの方法により、サーバーサイドのソフトウェアをテストし、セキュリティの脆弱性の有無を確認しておく必要があります。
- アプリ/システムの侵入テスト、または
- 脆弱性スキャン/静的解析。クラウドホスティングプロバイダーを使用している開発者は、クラウド構成もテストし、セキュリティ問題の有無を確認しておく必要があります。この要件は、ホスティングアプローチ(BaaS、PaaS、IaaS、セルフホスティング、ハイブリッドなど)にかかわらず該当します。

組織がSASTを開発プロセスに追加することを検討しているのであれば、NISTはオープンソースと商用ツールのリストを管理しており、ツール選択の出発点として有用であると思われます。

証拠資料に関するガイド

このセキュリティ保護の根拠を提出するよう求められた場合は、証拠資料の準備の説明に従って、ポリシー/手順と実装証拠の両方を準備してください。

組織がクラウドやサーバー環境内でプラットフォームデータを処理する場合:

侵入テストまたはSASTツールの実行が完了したことを示す証拠資料を提出してください。証拠資料には以下が含まれている必要があります。
- テストの範囲に関する記述
- テストが完了した日付 - 日付は過去12か月以内である必要があります
- テストで発見された脆弱性の概要またはリストのいずれか。概要またはリストには、深刻度の分類(重大、高い、中程度、低い、参考情報)が含まれている必要があります。通常は、未解決の重大な脆弱性または深刻度の高い脆弱性がないことが期待されます。

プラットフォームデータの処理に使用する、インターネットにアクセス可能なクラウドやサーバーソフトウェア(ウェブクライアントやモバイルクライアントが使用するREST APIなど)が許容されるには、このテストの範囲内である必要があります。

該当する場合(すなわち、AWS、GCP、Azureのようなクラウドホストを使用している場合)、たとえば、NCC Scout Suite、AWS Configなどの実行結果など、クラウド構成のレビューが実施されたことを示す証拠書類を提出してください。これが組織に該当しない場合は、クラウド構成のレビューが該当しない理由を説明した文書を、提出する証拠書類に含めてください。
証拠書類では詳細な脆弱性の再現ステップなどの機密情報を削除または編集してから提出してください

組織がクラウドやサーバー環境内でプラットフォームデータを処理しない場合:

侵入テストまたはSASTツールの実行が完了したことを示す証拠資料を提出してください。証拠資料には以下が含まれている必要があります。
- テストの範囲に関する記述
- テストが完了した日付 - 日付は過去12か月以内である必要があります
- テストで発見された脆弱性の概要またはリストのいずれか。概要またはリストには、深刻度の分類(重大、高い、中程度、低い、参考情報)が含まれている必要があります。通常は、未解決の重大な脆弱性または深刻度の高い脆弱性がないことが期待されます。
証拠書類では詳細な脆弱性の再現ステップなどの機密情報を削除または編集してから提出してください

証拠資料の例

侵入テスト - 組織が、Meta APIと統合してプラットフォームデータを処理する、サーバーサイドで実行するソフトウェアについて侵入テストを依頼します。テスト企業は、テストが完了したら、以下のような概要書を作成します。赤色の注記は、テストが実施された日付(過去12か月以内であること)、およびテスト(または該当する場合は再テスト)の終了時における未解決の深刻な(深刻度が重大/高い)テスト結果に関する概要の記載を強調しています。報告書の機密性の高い情報を編集(具体的には、詳細な脆弱性の再現ステップ)してから提出してください。

静的解析 - SASTツールなど、別の方法を使用している場合は、その結果を、SASTを実行した日付、および解析結果ごとの種類とその深刻度/重大度を記載したリストが含まれる文書にエクスポートしてください。

クラウド構成のレビュー

ある開発者は、クラウドプロバイダー(この場合はAWS)のデフォルトのルールセットを使用したNCC Scout Suiteを用いてクラウド構成をレビューし、脆弱性およびセキュリティ問題の有無を確認しています。このツールは、詳細の実行結果が含まれるJSONファイルを出力します。この例では、深刻度が「危険」としてフラグされている問題が多数あるため、開発者はレビューを実施して解決する必要があります。

未加工のNCC Scout Suite JSONファイルには、アップロードしてはならないクラウド環境に関する詳細が含まれます。代わりに、レスポンスを絞り込んで実行結果の数を重大度別に示します。

$ python3 scout.py aws –-no-browser
2022-08-22 11:39:38 localhost scout[76981] INFO Saving data to scoutsuite-report/scoutsuite-results/scoutsuite_results_aws-043954759379.js

$ cd scoutsuite-report/scoutsuite-results
$ tail -n +2 scoutsuite_results_aws-043954750000.js| jq '. | {last_run}' | pbcopy

{
  "last_run": {
    "ruleset_about": "This ruleset consists of numerous rules that are considered standard by NCC Group. The rules enabled range from violations of well-known security best practices to gaps resulting from less-known security implications of provider-specific mechanisms. Additional rules exist, some of them requiring extra-parameters to be configured, and some of them being applicable to a limited number of users.",
    "ruleset_name": "default",
    "run_parameters": {
      "excluded_regions": [],
      "regions": [],
      "services": [],
      "skipped_services": []
    },
    "summary": {
      "acm": {
        "checked_items": 4,
        "flagged_items": 2,
        "max_level": "warning",
        "resources_count": 2,
        "rules_count": 2
      },
      "awslambda": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "cloudformation": {
        "checked_items": 11,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 11,
        "rules_count": 1
      },
      "cloudfront": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 3
      },
      "cloudtrail": {
        "checked_items": 153,
        "flagged_items": 4,
        "max_level": "danger",
        "resources_count": 17,
        "rules_count": 9
      },
      "cloudwatch": {
        "checked_items": 2,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 2,
        "rules_count": 1
      },
      "codebuild": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "config": {
        "checked_items": 17,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 1227,
        "rules_count": 1
      },
      "directconnect": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "dynamodb": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 1,
        "rules_count": 0
      },
      "ec2": {
        "checked_items": 760,
        "flagged_items": 108,
        "max_level": "danger",
        "resources_count": 44,
        "rules_count": 28
      },
      "efs": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "elasticache": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "elb": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 3
      },
      "elbv2": {
        "checked_items": 42,
        "flagged_items": 4,
        "max_level": "danger",
        "resources_count": 0,
        "rules_count": 5
      },
      "emr": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "iam": {
        "checked_items": 801,
        "flagged_items": 27,
        "max_level": "danger",
        "resources_count": 87,
        "rules_count": 37
      },
      "kms": {
        "checked_items": 15,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 15,
        "rules_count": 1
      },
      "rds": {
        "checked_items": 1,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 27,
        "rules_count": 9
      },
      "redshift": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 6
      },
      "route53": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 1,
        "rules_count": 3
      },
      "s3": {
        "checked_items": 121,
        "flagged_items": 34,
        "max_level": "warning",
        "resources_count": 7,
        "rules_count": 18
      },
      "secretsmanager": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 1,
        "rules_count": 0
      },
      "ses": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 4
      },
      "sns": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 7
      },
      "sqs": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 8
      },
      "vpc": {
        "checked_items": 271,
        "flagged_items": 211,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 9
      }
    },
    "time": "2022-08-22 11:42:25-0400",
    "version": "5.11.0"
  }
}

開発者によるクラウド構成のレビューには、Amazon Web Servicesのルールセットを使用する方法もあります。

# Show that AWS Foundational Security Best Practices are enabled
$ aws securityhub get-enabled-standards                                                                                                            
{
    "StandardsSubscriptions": [
        {
            "StandardsSubscriptionArn": "arn:aws:securityhub:us-west-1:043954759379:subscription/aws-foundational-security-best-practices/v/1.0.0",
            "StandardsArn": "arn:aws:securityhub:us-west-1::standards/aws-foundational-security-best-practices/v/1.0.0",
            "StandardsStatus": "READY"
        }
    ]
}

# Show that aggregator is configured for a representative region used to process Platform Data
$ aws securityhub list-finding-aggregators

$ aws securityhub get-finding-aggregator --finding-aggregator-arn '{REPLACE-WITH-FINDING-AGGREGATOR-ARN}'


# Demonstrate that the ruleset is running by fetching active findings and counting the number of lines of output
$ aws securityhub get-findings --query 'Findings[?RecordState==`ACTIVE`]' --filters '{"GeneratorId":[{"Value": "aws-foundational-security","Comparison":"PREFIX"}]}' --output text | wc -l                                     

4876
# Demonstrate that there are no active critical severity findings
$ aws securityhub get-findings --query 'Findings[?Severity.Label==`CRITICAL`] | [?RecordState==`ACTIVE`] | [*][Title, GeneratorId]' --filters '{"GeneratorId":[{"Value": "aws-foundational-security","Comparison":"PREFIX"}]}'

[]

許容される代替的なセキュリティ保護

開発者が、BugCrowdプラットフォームやHackerOneプラットフォームなどを使用して機能している脆弱性開示プログラム(VDP)を運用している場合は、侵入テストや脆弱性スキャンの代わりに、これを代替的なセキュリティ保護として提示することができます。これを証明するには、以下の事項を示した証拠書類を提出する必要があります。

プラットフォームデータの処理方法に関してVDPの範囲に例外が存在しないこと
過去12か月以内に脆弱性に関する進行中の調査および報告があること(通常は、毎月1つ以上の有効な脆弱性レポートにより提示)
提出された(有効な)脆弱性は、CVSS 3.1などを使用して深刻度スコアが割り当てられていること
脆弱性が合理的な時間で解決されること(通常は、提出日から90日未満)

この場合、証拠書類には以下が含まれている必要があります。

範囲に関する記述、および、それがプラットフォームデータの処理に使用するソフトウェアとどのように相互関連しているか
過去12か月間のプログラムにおける実際の脆弱性に関する提出情報についてのレポートこのレポートには、脆弱性のタイトル、提出日、解決日(解決した場合)、および深刻度のカテゴリ/スコアが含まれている必要があります。

Metaのapp secretとAPIのアクセストークンを保護する

質問: Meta APIのアクセストークンとapp secretは、以下両方の方法で保護されていますか。

現在のアプリやユーザー以外からアクセス可能なクライアントデバイスにMeta APIのアクセストークンを保存しない。
クラウド、サーバー、またはデータセンター環境で保存される場合、別個のキー管理サービス(KMS)を用い、データボルト(HashicorpのVaultなど)を利用する。

意図

app secretとアクセストークンは、許可するアクションをMeta APIが判断する仕組みにおいてセキュリティの基本となります。不正な人物がこれらの認証情報にアクセスできる場合、この人物は(本物の開発者になりすまして) Meta APIを呼び出し、弊社がアプリに許可している任意のアクション(アプリのユーザーに関するデータをMeta APIから読み取るなど)を実行できる可能性があります。

開発者は、Metaのプラットフォームの使用の一環として機密認証情報にアクセスできます。具体的な内容は以下のとおりです。
- アクセストークン - アプリが承認されると、ソフトウェアは、それ以降のAPI呼び出しで使用されるアクセストークンと呼ばれる認証情報を取得します。
- app secret - Metaは、組織内の信頼できる人物(アプリ管理者など)のみがapp secretにアクセスできることを見込んで開発者とapp secretを共有します。
これらの機密認証情報を読み取ることができる不正な人物は、自分が開発者であるかのように(これはトークンのなりすましと呼ばれる場合があります)これらを使用してMetaのAPIを呼び出すことができ、この結果、プラットフォームデータへの不正なアクセスにつながります。
したがって、なりすましを防ぐために、これらの認証情報を不正なアクセスから保護する必要があります。

要件の概要

アクセストークン

クライアントデバイス上 - Metaのアクセストークンは、別のユーザーまたはプロセスが読み取ることができるように入力してはなりません。
サーバーサイド - Metaのアクセストークンをサーバーサイドで処理または保存する場合には、アクセストークンは以下を満たしていなければなりません。

別個のキー管理サービス(KMS)を用い、復号キーへのアクセスがアプリに限定されるデータボルト(HashicorpのVaultなど)を利用することで保護する
ログファイルに入力しない

app secret - 以下の2つのどちらかが該当する必要があります。

セキュリティが確保されたサーバー環境外でapp secretを公開しない(たとえば、app secretがネットワーク呼び出しによってブラウザーまたはモバイルアプリに返されない、モバイル、ネイティブクライアントまたはデスクトップクライアントに配信されるコードにapp secretが埋め込まれない)
ネイティブまたはデスクトップタイプでアプリを構成し、app secretが含まれるAPI呼び出しをMeta APIが信頼しないようにする必要がある

証拠資料に関するガイド

Meta APIのアクセストークンとapp secretを保護するためのポリシーに関するドキュメントを盛り込んでください。アプリがサーバーサイドでMetaのアクセストークンを処理する場合には、開発者が講じる保護を証明する証拠資料を盛り込んでください(ボルトの利用、値が暗号化フォーマットで保存されていることの証明、app secret証明が必須となっているアプリの設定など)。

提出する証拠には、app secretやアクセストークンのプレーンテキストの値を盛り込まない(削除する)ようにしてください。

証拠資料の例

ある組織は、Metaのapp secretなど、機密性の高いデータをセキュアに保存するのにAWS Secrets Managerを利用しています。

ある組織は、API呼び出しに関するapp secret証明を必須とするようMetaのアプリを設定しています。

許容される代替的なセキュリティ保護

データボルトまたはアプリレベルの暗号化により、サーバーサイドで保存するアクセストークンを保護しない場合には、以下を行うことができます。

キーだけがアプリにアクセスできるボルトまたはアプリレベルの暗号化を使用してapp secretを保護する
MetaへのすべてのAPI呼び出しでapp secret証明を必須とするようにアプリを設定する

上記1の方法を実行できない(必要な特定のAPI呼び出しがブロックされるため、app secret証明を必須とすることができない)場合には、Metaは、保存されているアクセストークンが不正使用されるリスクと比較して、アクセストークンが不正使用されるリスクを抑制するために開発者が導入している他の制御手段を考慮します。

インシデント対応プランの策定とインシデント対応システムおよびプロセスのテスト

質問: セキュリティインシデント(データ侵害やサイバー攻撃など)の対応に用いるシステムやプロセスのテストを少なくとも12か月ごとに実施していますか？

趣旨

セキュリティインシデントは、すべての会社でいつかは発生するため、組織が、インシデントを抑制するために誰が何を行うかを事前に計画しておき、関係者と連絡をとり、発生した事態から復旧してそこから学習することが重要です。

セキュリティインシデントが発生した場合、(すべきことのトレーニングを受けているチームと一緒に)プランまたはプレイブックを準備しておくと、インシデントの期間を短縮し、最終的にはプラットフォームデータの露出を制限できます。
組織が異なればインシデントへの対応の洗練度のレベルも異なりますが、弊社では、少なくとも、主な活動(検知、対応、復旧、審査)とともに、役割と責任が割り当てられて指名された人員が含まれる基本的なプランを必要としています。

要件の概要

開発者は以下を備える必要があります。

Metaの最低基準を満たすインシデント対応プラン
この文書に必要最低限含まれるべき要素: (1)役割と責任、(2)検知、(3)適用される法的義務に基づく対応(関係する管轄監督機関とデータ主体へのデータ侵害通知など)と復旧の手順、(4)インシデント後の審査プロセス
プランが最近(過去12か月以内に)テストされていること、およびプランで指名された人員がテストに参加したことを示す証拠書類

この要件は、プラットフォームデータのサーバー側で処理を行うかどうかにかかわらず適用されます。

証拠資料に関するガイド

証拠資料の準備に記載された説明に従って、ポリシー/手順書、および実装の証拠資料の両方を準備してください。

インシデント対応プラン(1つ以上の文書)を送信してください。これには、次のトピックが含まれている必要があります。役割と責任、検知、対応と復旧、インシデント後の審査
- インシデント対応計画を策定していない場合、インターネット上で役に立つリソースが数多く利用可能です。例えば、Counteractiveのインシデント対応プランのテンプレートや、参考資料とその他の記事などをご覧ください。
過去12か月間にプランをテストしたことを示す証拠資料を提出してください。この証拠資料の形式は様々ですが、以下が含まれている必要があります。
- シナリオの説明(例えば、ランサムウェア攻撃に対応するための机上訓練など)
- テストが行われた日付
- 各参加者の役割
- プランの役割と責任のセクションに名前が記載された人員のいずれかが参加していなかった場合は、それぞれについての理由
送信する前に、この証拠資料から機密性の高い情報を抹消(例えば、個人の氏名やメールアドレスなどのPIIなど)してください。証拠資料の例

インシデント対応プラン

開発者は、このテンプレートに基づき包括的なインシデント対応プランを策定しています。これらの画像に表示されているのは、目次だけですが、以下に完全なテンプレートへのリンクがあります。

完全なCounteractiveのインシデント対応プランのテンプレート (docx形式)を参照する

インシデント対応テスト

開発者は、机上訓練を通じてインシデント対応プランのテストを実施しており、このテンプレートに基づき、その結果を文書化してています。

ここに含まれているのは、最初の2ページのみですが、開発者は、文書全体を送信する必要があります。

リモートアクセス用の多要素認証の義務化

質問: クラウド環境やサーバー環境に接続できるアカウントや、Metaからのプラットフォームデータを保存するシステムの展開、維持、監視、運用のために使用するサービスにアクセスできるアカウントすべてに対して、リモートアクセス用の多要素認証を義務化していますか？

趣旨

攻撃者が機密データにアクセスするために使用する一般的な技術は、開発者がアプリ/システムを構築または操作するために使用するツールにアクセスすることから始まります。パスワードだけで保護されたアカウントに不正アクセスするための高度なツールが存在します。多要素認証を使用することで、このリスクを防止するためのセキュリティのレイヤーが強化されます。

ソフトウェア開発者は、さまざまなツールを使用してアプリ/システムを構築、展開、管理します。
これらのツールは、インターネットを介してリモートで使用するのが一般的です(たとえば、従業員が在宅勤務で新しいソフトウェア機能を納品したり、クラウド構成を更新する場合)。
単一要素認証(ユーザー名とパスワード)を使用して保護されたツールは、アカウントの乗っ取り攻撃を非常に受けやすくなります。たとえば、攻撃者はツールを使用して、1つのツールから流出したユーザー名とパスワードの組み合わせを試してみることで、別のツールにアクセスできます。
多要素認証では、ログイン時にパスワード以外の別の要素(認証システムアプリによって生成されたコードなど)を義務化することで、このような攻撃から保護します。

要件の概要

組織によるプラットフォームデータの処理に関し、以下のツールに対するリモートアクセスを多要素認証によって(つまり、パスワードのみの認証ではなく)保護する必要があります。

アプリ/システムに対するコード/構成の変更を展開および管理するために使用するツール
クラウドまたはサーバー環境への管理アクセス(該当する場合)

具体的には、以下の場合はMFAまたは許容される代替的なセキュリティ保護が必要です。

コラボレーション/通信ツール - ビジネスメールやSlackなど
コードリポジトリ - アプリ/システムのコード/構成に対する変更を追跡するために使用するGitHubまたは別のツールなど
さらに、プラットフォームデータをサーバーサイドで処理する場合:
- ソフトウェア開発ツール - クラウド/サーバー環境にコードを展開するために使用するツール(Jenkinsまたは別のContinuous Integration / Continuous Deployment (CI/CD)ツールなど)
- 管理ツール - クラウド/サーバー環境を管理/監視するために使用するポータルまたはその他のアクセス
- サーバーへのリモートアクセス - サーバーサイドで動作するサーバーにリモートでログインするために使用するSSH、リモートデスクトップ、または同様のツール

MFAの実装について:

SMSによるコードの送信よりも、認証アプリや認証ハードウェア(YubiKeyなど)の使用が望ましく、推奨されます。
ただし、組織は任意のMFAを実装することができます。

証拠資料に関するガイド

このセキュリティ保護の根拠を提出するよう求められた場合は、証拠資料の準備の説明に従って、ポリシー/手順と実装の証拠資料の両方を準備してください。

実装の証拠資料では、上記の環境に適用されるツール(すなわち、コラボレーションツール、コードリポジトリ、クラウド/サーバー展開、クラウド/サーバー管理ポータル、クラウド/サーバーリモートアクセス)においてMFAが実施されていることを示す必要があります。
実装は設定により以下のように異なります。
- たとえば、SSOプロバイダーを使用している場合は、組織のグローバル設定のスクリーンショット、またはアプリごとの設定のスクリーンショットを使用できます。
- SSOプロバイダーがない場合は、特定のツールの設定のスクリーンショットを使用できます。
いかなる場合も、MFAが有効なアカウントの例ではなく、すべてのユーザーにMFAが有効となっている証拠資料が必要です。

証拠資料の例

AzureAD

ある組織は、AzureADをシングルサインオンのソリューションとして使用しています。このポリシーでは、多要素認証が要求されます。

次に、このポリシーは、適用されるクラウドアプリにマッピングされます。この方法では、証拠資料に選択したアイテムセクション全体が示され、MFAが必要なクラウドアプリが明確にわかる必要があります。

Okta

このルールでは、すべてのログインにMFAが要求されます。

AWS IAM

これは、MFA構成を許可し、MFAがない場合は他のアクションを禁止するAWS IAMポリシーの一例です。

GitHub

ある組織は、組織内の全員に対してMFAが要求されるよう、GitHub認証を設定しました。

許容される代替的なセキュリティ保護

組織内に存在するがMFAが実施されていない種類のリモートアクセスについて、アカウントの乗っ取りを防止するために、次のいずれか1つ以上の対策を講じているかどうかを示す必要があります。
- 強力なパスワードの要件 - 最小限のパスワードの複雑性、辞書にある単語の使用の禁止、以前に流出したことが知られているパスワードの使用の禁止など
- 認証のリトライ間隔 - 同一ソースからのログイン試行が複数回失敗した場合の待機期間を段階的に長くするツールの使用
- 認証の自動ロック - ログイン試行が10回失敗したらアカウントへのログインを自動的にブロックするメカニズムなど

ユーザーアカウントを維持するシステムを実装する

質問:アカウントの維持(アクセスと権限の割り当て、撤回、確認)用のシステムを実装していますか？

趣旨

優れたアカウント管理対策を講じることは、プラットフォームデータにアクセスするためのアカウントの不正な使用を防止する重要な要素の1つです。特に、開発者は、リソースまたはシステムへのアクセスが必要なくなったときにアクセス権を撤回するよう徹底する必要があります。

アカウントは、ユーザーに対するシステム、データ、管理機能へのアクセス権の付与の管理における基本単位です。
アカウントには、特定のアクションを可能にするアクセス許可が付与されます。このため、アカウントが必要とする最小限のアクセス許可を付与することを推奨します。これは、最小権限の原則と呼ばれます。
ある人物が退職した場合、次のような理由により、ユーザーアカウントをすみやかに無効にすることが重要です。
- (1)この人物(元社員)によるアクセスを防止する
- (2)不正な人物がこのアカウントを気付かれずに使用する可能性を下げるたとえば、悪意のあるハッカーがソーシャルエンジニアリングを使用して、ITヘルプデスクにこのアカウントのパスワードをリセットさせる可能性があります。このアカウントが現在の社員に属している場合、この社員はログインできないことを報告する可能性が高いですが、このアカウントが依然としてアクティブだが退職した社員に属している場合、気付かれる可能性は低くなります。
これを念頭に、組織は、アカウントの管理、アクセス許可または権限の付与、必要なくなったアクセスの撤回を行うための体系的な方法を構築する必要があります。

要件の概要

開発者には、以下の各ツール/システム/アプリのアカウントを管理するためのツールまたはプロセスが必要です。
- 互いに連絡を取るために使用するもの(Slackやビジネスメールなど)
- ソフトウェアを納品するために使用するもの(コードリポジトリなど)
- システムを管理および操作するために使用するもの(プラットフォームデータの処理に適したもの)
開発者は、(少なくとも12か月ごとに)アクセス権を定期的に審査し、(1)アクセスが必要なくなったとき、および(2)アクセスが使用されなくなったときにアクセス権を撤回するプロセスを構築する必要があります。
また、開発者には、ある人物が退職したときにこれらのツールへのアクセス権をすみやかに撤回するプロセスも必要です。
Metaでは、以下は必須ではありません。
- 特定のツールを使用すること – 開発者は、Google Cloud IdentityやMicrosoft Azure Active Directoryなどのディレクトリ製品、AWS Identity and Access Management (IAM)などのクラウド製品を使用したり、定期的に最新の状態に保つスプレッドシートを使用したりできます。
- これらのさまざまなアクセスのタイプ全体にわたってアカウントを管理するための単一の統合ツールが存在すること。

この要件は、プラットフォームデータをサーバー側で処理するか否かを問わず適用されます。

証拠資料に関するガイド

証拠資料の準備に記載された説明に従って、ポリシー/手順書、および実装の証拠資料の両方を準備してください。

ポリシー/手順書 - アカウント管理方法を網羅する文書化されたポリシーと手順書のドキュメントを提供してください。このドキュメントには、アカウントの作成、権限の付与、最小限のパスワードの複雑性、アカウント閉鎖ポリシー、MFAポリシー、アカウントリセット手順、ならびにアクティブでない状態が一定期間経過した後および社員が退職した(社員が辞職した場合または解雇された場合)後のアクセス権の取り消しの手順が含まれることが想定されます。
実装の証拠資料 - アカウントを管理(または環境に該当していないことを明示)するために適用される以下のツールまたはプロセスの少なくとも1つから証拠を提供してください。(1)ビジネス用メールとコラボレーションツール、(2)コードリポジトリ、(3)クラウド/サーバーデプロイツール、(4)クラウド/サーバー管理ポータル、(5)クラウド/サーバーリモートログイン(SSHやリモートデスクトップなど)。代表的な個別のツールまたはプロセスの場合、以下を示す証拠を含めてください。
- 退職した社員がこれらのツールへのアクセス権を撤回した(ユーザーアカウントを現在の組織のメンバーの信頼できるデータと比較した照合レポートなど)
- 一定期間使用されていないアクセス権が撤回された(操作がない期間が最長3か月として設定されている場合に代表的なアクティブなユーザーアカウント所有者の最後のアクセス日が過去90日間以内であることを示すレポートなど)

証拠資料の例

ポリシー/手順書 - ある開発者は、アクセス権を付与、審査、撤回するための手順が含まれるアクセスライフサイクル管理基準を作成しました。

実装例 - 退職した社員のアクセス権の撤回

ある開発者は、現在の雇用形態を含む人事(HR)データの信頼できる情報源としてWorkdayを使用しています。この開発者は、ユーザーアカウントの管理および情報システムとツールへのアクセス権付与のためのアイデンティティプロバイダー(IdP)としてGoogle Cloud Identityを使用しています。

ある開発者は、現在の社員のWorkdayレポートに従ってアクティブな社員ではない社員のアクティブユーザーアカウントがGoogle Cloud Identity内に存在しないことを示す最近の(過去12か月以内など)照合レポートが実行されたことを示すレポートを提出することで、退職した社員のアクセス権が撤回された証拠を提出しています。

実装例 - 使用されなくなったアクセス権の撤回

ある開発者は、ユーザーアカウントの管理および情報システムとツールへのアクセス権付与のためのアイデンティティプロバイダー(IdP)としてGoogle Cloud Identityを使用しています。

ある開発者は、使用されなくなった(過去6か月以内にログインが行われなかった)ときにアクセス権が撤回された証拠を提出しています。これを行うには、最後のサインイン別に並び替えられたユーザーディレクトリを提出して、最後のサインインが過去6か月より古いアクティブユーザーアカウントが存在しないことを示します。

実装例 - GitHub (コードリポジトリ)

ある開発者は、ID管理および情報システムとツールへのアクセス権付与のためにシングルサインオン(SSO)ツールを使用しています。この開発者は、SSO認証を義務付けるようGitHubを設定しました。

ソフトウェアを最新の状態に保つ

質問:システムコードと環境(サーバー、仮想マシン、ディストリビューション、ライブラリ、パッケージ、ウイルス対策ソフトウェアを含む)を最新の状態に維持するためのシステムを実装していますか？

購入意思

ソフトウェアコンポーネントは、セキュリティの脆弱性を解決するために定期的に更新またはパッチ適用されており、これらのコンポーネントは最終的にサポートされなくなると廃止されます。これらのコンポーネントをパッケージ化または使用する開発者は、既知の脆弱性があるソフトウェアを実行するのを回避するために最新の情報を取り入れ続ける必要があります。

アプリ開発者は、プラットフォームデータを処理するアプリ/システムを実行するためにさまざまなサードパーティのソフトウェアを使用します。
たとえば、開発者は、以下の一部またはすべてを使用します。
- ライブラリ、SDK、パッケージ - 開発者は、これらを独自のカスタムコードとともにパッケージ化してアプリを構築します
- 仮想マシン画像、アプリコンテナ、オペレーティングシステム - アプリがこれらの1つ以上のコンテナ内で動作し、これらのコンテナが仮想化やネットワークとストレージへのアクセスなどのサービスを提供します
- 社員/貢献者によって使用されるブラウザー、オペレーティングシステム、その他のアプリケーション - 開発者がシステムを構築および実行するために使用するモバイルデバイスやノートパソコン上で動作するソフトウェア
セキュリティの脆弱性はこれらのコンポーネントで定期的に発見されており、その結果としてパッチがリリースされています。
その後、パッチによって修正された脆弱性が重大度評価(低、中、高、重大)とともにパブリックデータベース内で開示されます。
したがって、Metaのプラットフォームを使用する開発者には、以下の方法によってパッチを管理する体系的な手段が必要です。
- アプリ/システムに関連するパッチを特定する
- 露出に基づいて緊急性に優先順位を付ける
- 継続中のビジネスアクティビティとしてパッチを適用する

要件の概要

以下のソフトウェアコンポーネントの場合、開発者は必要に応じて、セキュリティの脆弱性を解決するために使用可能なパッチを特定する、リスクに基づいて優先順位を付ける、継続中のアクティビティとしてパッチを適用するために定義された再現可能な手段を策定する必要があります。

クラウドまたはサーバー環境で使用されるライブラリ、SDK、パッケージ、アプリコンテナ、オペレーティングシステム
クライアントデバイス上(モバイルアプリ内など)で使用されるライブラリ、SDK、パッケージ
アプリ/システムなどを構築および操作するためにメンバーによって使用されるオペレーティングシステムとアプリケーション(社員のノートパソコン上で動作しているオペレーティングシステムとブラウザー)

Metaでは、これらの活動に特定のツールを使用する必要はありません。組織が各種ソフトウェアを最新の状態に保つためにさまざまなアプローチを使用するのは一般的です(アプリと一緒にパッケージ化されたライブラリや社員のノートパソコンのオペレーティングシステムのアップデートなど)。

この要件はホスティングアプローチ(BaaS、PaaS、IaaS、自己ホスト型、ハイブリッドなど)とは関係なく適用されますが、最新の状態に保つ責任を負う一連のコンポーネントは変化します。

以下の図は、さまざまなアーキテクチャの種類のどこでパッチを適用する必要があるかを示しています。

証拠資料に関するガイド

この保護の根拠を提出するよう求められた場合は、証拠の準備の説明に従って、ポリシー/手順と実装証拠の両方を準備します。

環境内のソフトウェアの範囲内の種類(ライブラリ、SDK、パッケージ、仮想マシン画像、アプリコンテナ、オペレーティングシステム、ブラウザー、社員/貢献者が使用しているアプリケーション)を特定することから始めます。

以下の活動に使用する1つ以上のツールがある場合があります。

インベントリー - スクリーンショットを介したドキュメント、またはパッチを適用する必要がある範囲内のライブラリ、パッケージ、SDK、コンテナ、アプリサーバー、オペレーティングシステムのリストを最終的に表すツールまたはプロセスを示すドキュメント。ソフトウェアの種類(クラウドアプリ、クライアントアプリ、社員のデバイスなど)の担当者用のインベントリーが必要です。
利用可能なソフトウェアパッチの特定 - インベントリーに関連して存在するソフトウェアパッチを特定するためのツールまたはプロセスが必要です。
優先順位付け - 関連するパッチに優先順位を割り当てるためのツールまたはプロセス(Jiraチケット、GitHubの問題、トラッキングスプレッドシートなど)が必要です。
- パッチの適用
- スクリーンショットを介したドキュメント、またはパッチが特定されて優先順位付けされた後に、パッチがさまざまな適用先に展開されることを示すドキュメント。
生産終了(EOL)ソフトウェアの解決と使用のタイミングに関するポリシーが含まれます。

証拠資料の例

NodeJSアプリ用のSnyk - 開発者が、Synkコマンドラインインターフェイス(CLI)を使用して、既知のセキュリティの脆弱性があるパッケージ化されたサードパーティの依存関係を特定し、これらの脆弱性の重大度に基づいて優先順位を付けます。

NPM監査

開発者が、NPM監査を使用して、ノードアプリケーションで使用されている依存関係の脆弱性を見つけます。以下の画像の例は、パッチの適用が必要な重大度の高い複数の脆弱性を示しています。

Trivy

開発者が、Trivyを使用して、マシン画像内の脆弱性を見つけます。以下の画像の例は、この画像に含まれる、パッチの適用が必要なライブラリ内の重大度の高い脆弱性を示しています。

Windows Server Update Services (WSUS)

開発者が、Windows Server Update Services (WSUS)を使用して、サーバーとPC/ノートパソコンを管理します。以下の画像の例は、Windowsの更新プログラムを確認、承認、展開できるWSUSツールの管理者ビューを示しています。

プラットフォームデータへのアクセスを記録し、プラットフォームデータの送信先と保存先を追跡するシステムを導入する

意図

信頼できるログファイルがなければ、開発者がプラットフォームデータへの不正アクセスを検知することは困難です。

監査ログを用いると、特定のユーザーがプラットフォームデータを含むデータベースのテーブルに対してクエリを実行したなど、あるイベントが生じたという情報を記録することができます。
その結果、こうしたログにより、不審なアクティビティに基づいた自動アラートの生成や、セキュリティインシデントが特定された後のフォレンジック分析といったプロセスをサポートすることができます。

要件の概要

プラットフォームデータをサーバーサイドで処理する場合には、その環境において以下の事項を行う必要があります。

主要なイベント(プラットフォームデータへのアクセス、高度なアクセス許可を有するアカウントの使用、監査ログの設定変更など)を記録する監査ログを維持する
監査ログは、セントラルリポジトリに統合し、変更や削除から保護する

証拠資料に関するガイド

証拠資料のアップロードを求められた場合には、以下の事項を証明する必要があります。

システムの全体図を示し、プラットフォームデータを保存するサービスを指定し、イングレスおよびエグレスのポイント(別の外部サービスに対して行われることが予想される転送を含む)を示す最新のデータフロー図などを通じて、プラットフォームデータの保存、アクセス、転送方法について最新の理解をしていること
不正防止機能の付いた監査ログを実装していること
プラットフォームデータへのアクセスに関するイベントがログに取り込まれていること

プラットフォームデータがシステム(例えば、サードパーティやパブリックエンドポイントなど)から移転される可能性がある場合におけるプラットフォームデータの移転のモニタリングと主要なポイント

趣旨

プラットフォームデータがどのように処理される予定であるかを把握することと、その後の実際の処理をモニタリングすることは、プラットフォームデータが意図された目的にのみ使用されていることを組織が確認するための重要な方法です。

開発者は、プラットフォームデータの保管、ネットワーク送信およびバックアップ(別の場所で複製される場合があります)への書き込み方法について最新状況を把握しておく必要があります。
例えば、モニタリングによって、プラットフォームデータが予期せぬ方法で送信されている状況を特定できたり、適切な送信時の暗号化なしにネットワークを介して送信されているかどうかを特定できたりする場合があり、これにしたがって、対応策を講じることができます。

要件の概要

プラットフォームデータをサーバーサイドで処理する場合には、そのサーバー環境において以下の事項を行う必要があります。

プラットフォームデータが保管、処理、ネットワーク送信される場所を正確に示すデータフロー図を維持する
プラットフォームデータのシステム外部への移転のモニタリングを設定する(例えば、自動モニタリング製品による監査ログなど)
可能な場合、アラートが生成されるようモニタリングシステムを設定し、プラットフォームデータの予期せぬ移転が発生した場合には速やかにそれを審査する(次の要件も参照してください - ログやその他のセキュリティイベントをモニタリングし、異常なイベントやセキュリティ関連イベントのアラートを生成する自動システムを導入する)

証拠資料に関するガイド

以下を示す証拠資料を提出してください。

システムの全体図を示し、プラットフォームデータを保管するサービスを指定し、イングレスおよびイーグレスのポイント(別の外部サービスに対して行われることが予想される転送を含む)を示す最新のデータフロー図などを通じて、プラットフォームデータの保管、アクセス、転送方法について最新の理解をしていること
不正防止機能の付いた監査ログが実装されていること
プラットフォームデータの移転に関連するイベントは、ログにキャプチャされること(イベントには、日時、操作を行ったユーザーまたはアプリの特定、送信元と送信先が含まれる必要があります)

ログやその他のセキュリティイベントをモニタリングし、異常なイベントやセキュリティ関連イベントのアラートを生成する自動システムを導入する

意図

インターネットでアクセスできる現代のシステムにおいて、予想外の行動を確認、特定するのに人間の力に頼ることは現実的ではありません。その代わりに、ログファイルやその他のシグナルを取り込み、人間によるさらなる調査が必要だという警告を発することのできるツールが存在します。

要件の概要

プラットフォームデータをサーバーサイドで処理する場合には、そのサーバー環境において以下の事項を行う必要があります。

ログファイルやその他のイベントを取り込むことができるツールを導入し、作動した場合に警報を発するルール、および担当者（待機中のセキュリティ調査員など）に警報を転送する仕組みを確立する
関連するシグナル(ウェブのアクセスログ、認証の試み、高度な権限を有するユーザーがとるアクションなど)をそのツールに取り込む
経時的にルールを調整、改良し、シグナルとノイズのバランスを取る(誤警報が多すぎる状況を回避しつつも、調査に値するイベントを無視しないなど)

証拠資料に関するガイド

この目的のため、開発者は一般に、以下のようなセキュリティ情報・イベント管理(SIEM)ツールを採用しています。

McAfee Enterprise Security Manager
SolarWinds Security Event Manager
Splunk Enterprise Security
Sumo Logic

関連するシグナルのソースが選択したツールに転送されること、トリガーや警報が設定されていること、フォローアップを担当する職員に警報が転送されること、および定期的に警報を調整するプロセス(毎月のレビューや更新サイクルによるものなど)があることを示す証拠資料を提示する必要があります。

用語解説

A

サードパーティ - リスク管理用語において、サードパーティとは、Metaのプラットフォーム上の開発者をいいます(ファーストパーティはMeta自身、セカンドパーティはMeta製品のユーザーです)。

フォースパーティ - リスク管理用語において、フォースパーティとは、開発者が自身のビジネスを可能にするために依拠するサービスの提供企業をいいます(ファーストパーティはMeta、セカンドパーティはMetaのユーザー、サードパーティはMetaのプラットフォーム上の開発者です)。アクセストークン - パスワードなどの認証情報で、これにより、ソフトウェアはAPIを呼び出して何らかの操作(例えば、ユーザープロフィールからのデータの読み取りなど)を実行することが可能になります。

Amazon Web Services (AWS) - Amazonの一連のクラウドコンピューティングサービス。

アプリ専用ID (ASID) - ユーザーがアプリを利用することを選択したときにMetaが生成する一意の識別子。ASIDでは、一人のユーザーが2つのアプリを使用する場合、アプリごとにASIDが異なるため、異なるアプリにまたがってデータセットとユーザーを関連付けることが困難になります。そのため、ユーザーのプライバシーの向上に役立ちます。

アプリシークレット - Metaがアプリのダッシュボードを介して開発者に提供する共有の秘密のキー。アプリシークレットを保持することで、グラフAPIを通じてソフトウェアに操作の実行を許可できるため、開発者は、無許可の当事者がアプリシークレットにアクセスできないように注意する必要があります。

アプリのセキュリティ侵害 - 悪意のある行為者がアプリ内の不適切な設定や脆弱性(ウェブアプリのソフトウェア脆弱性など)を通じて組織の内部ネットワークに不正にアクセスできた場合、これをアプリのセキュリティ侵害といいます。アプリのセキュリティ侵害に対する防御策は、アプリの侵入テストを実施することです。ネットワークのセキュリティ侵害も参照してください。

アプリケーションコンテナ - コンテナによって、ソフトウェアコードと関連する依存関係をパッケージ化することで、様々なタイプのサーバー(例えば、LinuxやWindows Serverなどの異なるオペレーティングシステムを実行するサーバーなど)上でアプリを実行できるようになります。開発者は、アプリをパッケージ化するコンテナイメージを作成します。コンテナイメージは、アプリケーションコンテナエンジンまたはランタイムによってホスト(実行)されます。

アプリケーションの暗号化 - データを保護するための方法で、アプリケーションソフトウェア自体が暗号化と復号の操作を実行します。これとは対照的に、Transport Layer Security (TLS)は、アプリケーションがリモートサーバーへの安全な接続を(HTTPSを使用するなどして)確立した場合に送信データをシームレスに暗号化し、また、クラウドプロバイダーは、保存データを透過的に暗号化するサービスを提供します。

Application Programming Interface (API) - 2台のコンピューターがネットワークを介して相互に対話することを可能にします(例えば、モバイルアプリが一元化された天気予報システムから特定の場所の当日の天気を取得するなど)。

アプリシークレットの証拠 - MetaへのAPI呼び出しのセキュリティをさらに強化するためのもので、これにより、開発者は、自身がアプリシークレットを保持していることを証明するパラメーター(アプリシークレットの証拠)を生成します。アプリシークレットの証拠は、アプリシークレットとアクセストークンに基づくハッシュ関数(一方向性関数ともいいます)の結果です。グラフAPIの呼び出し時にアプリシークレットの証拠を要求するようアプリを設定することで、ユーザーのアクセストークンのセキュリティ侵害による潜在的被害を軽減することができます。これらのアクセストークンは、さらなるアプリシークレットの証拠パラメーターがなければ使用できないからです。

B

サービスとしてのバックエンド(BaaS) - 開発者がフロントエンド(アプリのうち、ユーザーが操作する部分)の構築に集中できるよう、アプリ開発者にサーバーサイドの機能一式を提供するクラウドコンピューティングの一形態。BaaSソリューションは、PaaSに類似していますが、ユーザー認証やモバイルプッシュ通知のようなその他のサービスが追加されています。例えば、一般的なBaas製品には、次のようなものがあります。AWS Amplify、Azure Mobile Apps、Firebase、MongoDB Switch。

C

暗号文 - 暗号化データの類義語。暗号文は、何らかの暗号化アルゴリズムにより判読不能にされたデータの名称です。暗号文の対義語は、プレーンテキストです。

クライアントサイド - 通常、インターネットでアクセス可能なサービスを利用する場合、ブラウザーでウェブサイトを開くか、携帯電話やタブレットでモバイルアプリを実行します。ブラウザーやモバイルアプリは、ローカルクライアントまたはクライアントサイドと呼ばれます。クライアントは、インターネットを介してリモートコンピューター(サーバー)にリクエストを送信します。

クラウドコンピューティング - サーバーコンピューター、ネットワークおよびストレージの管理の一様式で、これにより組織は物理的環境(すなわち、サーバーラックやネットワークケーブルでいっぱいのデータセンター)について心配する必要がなくなります。代わりに、組織は、これらの資産をオンデマンドでプロビジョニングして、利用したサービスに応じて料金を支払うことができます。

クラウド設定 - ソフトウェアを実行するクラウドプロバイダーの利用に関して組織が設定したクラウドコンピューティングのオプション一式。クラウド設定の例には、許可またはブロックするネットワーク接続の種類、ログファイルが書き込まれる場所とその保存期間、クラウド設定を変更する権限のある一連のユーザーなどがあります。

補完コントロール - 一連の基本的要件とは異なるが、リスクに対して同等の保護を提供することを意図したセキュリティコントロール。

D

データベース - 任意のデータの保存、読み取り、更新、削除を可能にするソフトウェア。データベースは、クライアントおよびサーバー上で実行することができます。Metaプラットフォームと連携する組織は、通常、グラフAPIから取得したデータを、サーバーサイドで実行するデータベースに保存します。

復号 - 暗号化されたデータを元の形式に変換するプロセス。つまり、復号によって、暗号文をプレーンテキストに変換します。

E

暗号化 - 復号できなければ、使用できない形式にデータを変換するプロセス。つまり、暗号化によって、プレーンテキストを暗号文に変換します。

保存データの暗号化 - 永続ストレージ(ディスクドライブなど)への書き込み時に暗号化によって保護されているデータ。保存データの暗号化によって、不正アクセスに対する保護が強化されます。ストレージデバイス上の未加工ファイルを読み取れる行為者は、暗号文を表示できますが、復号キーにもアクセスできない限り、これを復号できないからです。

送信データの暗号化 - ネットワーク送信時に暗号化によって保護されているデータ。送信データの暗号化によって、ネットワーク経路での盗聴に対する保護が強化されます。ネットワークパケットを読み取れる行為者は、暗号文を表示できますが、復号キーにもアクセスできない限り、これを復号できないからです。

サポート終了(EOL)ソフトウェア - 組織がソフトウェア製品のサポート(セキュリティ脆弱性を解決するパッチの作成など)の終了を決定した場合、そのソフトウェアは、EOLソフトウェアとみなされます。こうしたソフトウェアは、メンテナンスされなくなるため、EOLソフトウェアを実行することは非常に危険です。

G

Google Cloud Platform (GCP) - Googleの一連のクラウドコンピューティングサービスグラフAPI - アプリがMetaソーシャルグラフへの読み取りと書き込みを行うための主な方法。MetaのSDKおよび製品は、すべて何らかの方法でグラフAPIを利用します。

H

ハッシュ関数 - 任意のデータを入力値として受け取って、元の入力値に復元できない短いコードを出力する暗号化機能。暗号化では、ハッシュ関数を使用してパスワードなどのデータを保護します。ユーザーのパスワードをプレーンテキストで保存すると盗まれる可能性があるため、ハッシュ関数によりパスワードを変換してから保存します。その後、ユーザーが正しいパスワードを入力したことを確認するために、システムは、同じハッシュ関数を使用して、入力データを変換して生成されたハッシュを、保存されていた値と比較します。出力されたハッシュは、元の入力値に復元できないことから、一方向性関数とも呼ばれます。

ホスティング環境 - 組織が自己所有のデータセンター、または他の顧客と共同設置(コロケーション)したデータセンター内で稼働させるリモートサーバー、ネットワークおよびストレージデバイス一式をいいます。この方式は、クラウドコンピューティングが普及したことから、最近では、あまり一般的ではなくなっています。

I

IDプロバイダー(IdP) - デジタルIDの管理を一元化して、ユーザーを認証するために利用するクラウドサービス。IdPを利用する組織は、一般に、IdPに依拠してユーザー認証を行うようクラウドアプリを設定します。これにより、ユーザーアカウントの作成、選択されたアプリへのアクセス権の付与、ユーザーアカウントの無効化を、各クラウドアプリで繰り返し行うのではなく、IdP内で一元的に行うことで、ユーザーを管理できるようになります。

IDとアクセス管理(IAM) - アカウント管理とシステムのアクセス権の付与に使用されるツールとプロセスのカテゴリをいいます。

サービスとしてのインフラストラクチャ(IaaS) - 顧客が物理的資産(例えば、サーバー、ネットワーク機器、ストレージアレイなどでいっぱいのデータセンターの管理など)に自ら責任を負うことなく、コンピューティング、ストレージおよびネットワーキングサービスを設定できるようにするクラウドコンピューティングの手法です。PaaSと比較して、IaaSでは、組織のクラウド資産に対する管理権限が強くなりますが、資産管理の複雑性が増すという代償が伴います。例えば、一般的なIaaS製品には、次のようなものがあります。AWS EC2、Microsoft Azure IaaS、Google Compute Engine。

L

ライブラリ - 事前に作成されたソフトウェアの構成要素で、通常、外部の会社や開発者から取得し、別の開発者のアプリやシステム内で一定のタスクを処理するために使用されます。ライブラリは、アプリの開発を簡略化します。特定の機能のライブラリがすでに存在していれば、開発者は一から作り直す必要がなくなるからです。ただし、ライブラリには、セキュリティの脆弱性が含まれていたり、それ自体に脆弱性がある他のライブラリが含まれていたりする可能性があるため、開発者は、ライブラリを自身のアプリの一部として使用する場合、使用されているライブラリを把握し、それらを常に最新に保つ必要があります。

M

モバイルクライアントまたはモバイルアプリ - モバイルアプリストア(iOS App StoreやGoogle Playストアなど)から携帯電話やタブレットにインストールされるアプリ。モバイルクライアントは、インターネットを介して組織のREST APIと通信するのが一般的ですが、他の当事者とも通信する場合があります(Android用Facebook SDKを介したグラフAPIとの通信など)。

多要素認証 (MFA) - アプリやシステムにアクセスするために複数の要素を要求する認証手法。MFAは、パスワードだけに依拠してユーザーを認証する単一要素認証とは対照的に、通常、パスワードのほかに、メールまたはSMSを通じて送信されるコード、認証アプリからのコード、生体スキャン、セキュリティキーのいずれか1つ以上を要求します。MFAは、無許可の行為者が、アカウントへのログインを繰り返し試みたり、知っているメールアドレスや一般的なパスワードを成功するまで使用してアカウントに侵入するのを困難にすることで、アカウントの乗っ取りを防止します。

N

ネイティブソフトウェア - ダウンロードして、ノートパソコンやモバイルデバイスにインストールされるアプリをネイティブソフトウェアといいます(iOS用Facebookアプリなど)。これとは対照的に、ブラウザー内で実行するアプリは、ウェブアプリと呼ばれます(Chromeブラウザーを使用してFacebookを開くなど)

ネットワークのセキュリティ侵害 - 悪意のある行為者がネットワーク自体における不適切な設定や脆弱性を通じて組織の内部ネットワークに不正アクセスした場合、これをネットワークのセキュリティ侵害といいます。ネットワークのセキュリティ侵害に対する防御策は、インターネットに接続されたネットワークにおける不適切な設定や脆弱性を特定するためにネットワークスキャンを実行することです。アプリケーションのセキュリティ侵害もご覧ください。

ネットワークスキャン - 次のような目的でソフトウェアを利用するリスク管理プロセス。(1)リモート通信に応答するネットワーク上のアクティブなサーバーを特定し、その後、(2)これらのいずれかのサーバーが、1つ以上のセキュリティエクスプロイトに対して脆弱であることが判明している旧バージョンのソフトウェアを実行していないか確認するため。組織は、定期的にネットワークスキャンを実行することで、自身のネットワーク境界上に予期せぬオープンポートが存在しないことなどを確認することができます。

Node Package Manager (NPM) - 事前に作成されたパッケージを開発者のアプリやシステムで使用可能にすることで、開発時間を短縮するためにJavaScriptの開発者が使用するツール。NPMには、アプリが使用するパッケージのセットを監査する機能や、既知のセキュリティ脆弱性を特定する機能が含まれています。

O

オブジェクトストレージバケット - クラウド内の永続ストレージの一種。これにより、組織は、ファイル(非常に大容量のファイルを含む)を永続ストレージに保管することが容易になり、ストレージアレイなどの物理的資産の拡張や、火災・洪水などの災害時にファイルが消失しないよう、バックアップする方法について心配する必要がなくなります。

オペレーティングシステム - コンピューターやモバイルデバイス上で実行するソフトウェア。これにより、アプリケーションは、コンピューターのプロセッサ、メモリ、ストレージ、ネットワークリソースを実行して、使用することが可能になります。例えば、MicrosoftのWindows、AppleのmacOSやiOS、Linuxなどがあります。

組織のメンバー - 社員、契約業者、派遣社員、インターン、ボランティアなど、組織内で役割や責任を担う人員。

組織のデバイス - 組織のメンバーが組織のための業務遂行に関連して使用するコンピューターやモバイルデバイス。

P

プラットフォーム利用規約の第6.a.i項 - Metaのプラットフォーム利用規約のセクション(6)の見出し(a)の(i)項を指しており、データセキュリティに関するプラットフォーム開発者の義務を定めています。

パッケージ - ライブラリの類義語。

パッチ - セキュリティ脆弱性の解消、不具合の修正、新機能の追加などを行うためのソフトウェアのアップデート。オペレーティングシステム、コンテナ、ライブラリ、SDKなど、あらゆる種類のソフトウェアには、パッチが適用されます。

侵入テスト - アプリやシステムに対する模擬攻撃で、テストの実施者は、これにより、無許可の行為者に悪用されるおそれのあるコードや設定の脆弱性の発見に努めます。侵入テストでは、サイバー犯罪者と同様のツールを使用して、調査を実施したり、潜在的な弱点を見つけるためのスキャンを実行したり、不正アクセスに利用されるおそれのある脆弱性をテストしたりします。侵入テストが完了したら、テスト実施者は、発見事項とそれぞれの重大度をまとめたレポートを作成し、ソフトウェアのメンテナンスを行う組織は、脆弱性を解消するための修正プログラムの作成に責任を負います。

プレーンテキスト - 暗号化されていないデータの類義語。つまり、暗号化により保護されていないデータの名称です。サービスとしてのプラットフォーム(PaaS) - クラウドプロバイダーが管理するプラットフォームに顧客がアプリケーションを展開するクラウドコンピューティングの手法。IaaSと比較して、PaaSでは、物理的資産(すなわち、サーバー、ストレージデバイス、ネットワーク機器)だけでなく、顧客がアプリを実行するオペレーティングシステムやアプリケーションコンテナもクラウドホストによって管理されるため、顧客の管理が簡素化されます。例えば、一般的なPaaS製品には、AWS Elastic Beanstalk、Google App Engine、Force.comなどがあります。

ポート - クライアントがインターネットを介してサーバーに接続する場合、受信先のアドレスには、次の2つのポートがあります。(1)サーバーのインターネットプロトコル(IP)アドレスと、(2)特定のアプリケーションが応答するサーバーのポート番号。一般的なプロトコルは、予約されたポートを使用しますが(例えば、HTTPSは443を使用)、開発者は、必要に応じて、ネットワーク通信にカスタムポートを使用することができます。

R

REST API - クライアントとサーバーがHTTPプロトコルを使用して通信するウェブアクセス可能なサービスの構築様式で、広く採用されています。Metaプラットフォーム上の開発者は、モバイルアプリとの間でプラットフォームデータを送受信するapi.example.comのようなサブドメインでREST APIをホストする場合があります。

S

Secure Shell (SSH) - 管理者がリモートでサーバーにログインし、そのサーバー上のプログラムを実行できるようにする通信スキーム。Telnetのような旧プロトコルと異なり、クライアントとサーバー間の通信を盗聴から保護することから、Secure(安全)と呼ばれます。また、Secure Socket Shellとも呼ばれます。

Secure Sockets Layer (SSL) - 今では使われなくなった、安全でないバージョンのデータ送信時の暗号化。安全な最新バージョンは、Transport Layer Security (TLS)と呼ばれます。

サーバー - ネットワークを介してリモートでサービスを提供するコンピューター。ブラウザーやモバイルアプリは、インターネットを介してサーバーに接続します。

サーバーレスコンピューティング - クラウドコンピューティングの一形態で、クラウドホストが物理的インフラストラクチャ、サーバーオペレーティングシステムおよびコンテナを管理します。開発者は、カスタムコード、関連ライブラリ、およびクラウド設定にのみ責任を負います。

サーバーサイド - ネットワーク接続の反対側(すなわち、サーバー上)のデータまたはコンピューティングをサーバーサイドといいます。それに対し、ノートパソコンやモバイルデバイスなどのローカルデバイス上のデータやコンピューティングは、クライアントサイドと呼ばれます。

シングルサインオン(SSO) - アプリがユーザーを認証する際に一元的なユーザーディレクトリ(すなわちIdP)に依拠する仕組み。組織のユーザーアカウントとアプリのアクセス管理の一元化に加え、ユーザーは、様々なアプリごとに異なる認証情報(ユーザーネームとパスワードなど)を持つ必要がなくなり、1つに統一された認証情報だけで済むという利点があります。

ソフトウェア開発キット(SDK) - 開発者が必要に応じて開発プロセスを簡略化するために使用できるコードの構成要素。例えば、Metaは、iOSおよびAndroid開発者用のグラフAPIでの作業を簡略化するSDKを作成・維持しています。ライブラリと同様に、自身のアプリにSDKを使用する開発者は、SDKを常に最新に保つ必要があります。

サービスとしてのソフトウェア(SaaS) - これを利用することで、顧客はクラウドベースアプリをインターネット経由で使用することができます。PaaSやIaaSとは異なり、カスタムコードの展開や、SaaSアプリの設定、アップグレード、パッチ適用は、SaaSソフトウェアベンダーが責任を負うため、SaaSアプリの顧客は、これらを一切行う必要がありません。例えば、一般的なSaaS製品には、Dopbox、MailChip、Salesforce、Slackなどがあります。

静的解析 - 静的アプリケーションセキュリティテストを参照してください。

静的アプリケーションセキュリティテスト(SAST) - ソースコードに対して専門ツールを実行することで、ソフトウェアの脆弱性を発見する手法。SASTツールは、潜在的な脆弱性(OWASP Top 10プロジェクトのリストに記載されるものなど)を特定します。開発者は、その後、結果の審査、真陽性と偽陽性の区別、ソフトウェアの脆弱性の修正を行います。SASTにより、開発者が脆弱性を本番環境に展開する前に見つけられるようにする点で役立ちますが、侵入テストのようにアプリの本番環境での設定に関連する脆弱性を見つけることはできません。

T

透過的データ暗号化 - 保存データ暗号化の一種で、通常、データベースのストレージ(すなわち、データベースのコンテンツ自体とそのログファイル)に適用されます。この仕組みでは、データベースソフトウェアが暗号化キーを管理し、透過的に暗号化操作(書き込み時)と復号操作(読み取り時)を処理します。

Transport Layer Security (TLS) - データ送信時の暗号化スキーム。ネットワーク経由で送信されるデータを、ネットワーク経路における盗聴から保護するために暗号化を使用します。TLSは、今では使われなくなった旧テクノロジーであるSSLに代わり、安全であり最新です。

2要素認証(2Fac) - 多要素認証の類義語。ボルト - 暗号化キー、アクセストークン、その他の認証情報などの機密性の高いデータ用の機密管理システム。ボルトは、機密に対するアクセス権者の厳格な管理を可能にするほか、監査ログの保存のような、その他のサービスも提供します。

V

仮想マシン(VM) - アプリケーションコンテナと非常に類似していますが、アプリケーションコンテナはコンテナエンジンで動作するのに対して、VMはハイパーバイザーと呼ばれるホストで動作します。VMイメージには、オペレーティングシステムが含まれますが、アプリケーションコンテナには含まれないことが、主な相違点です。アプリケーション、およびライブラリなどの依存関係は、VMとアプリケーションコンテナのどちらにも含まれます。

仮想プライベートクラウド(VPC) - クラウドがない時代のデータセンターでの従来のネットワークに類似するクラウドリソースセットを指すためにAWSが使用する用語。

脆弱性 - システムやアプリの欠陥で、読み取り権限のない行為者がデータを読み取るためなどに悪用されるおそれがあるもの。

脆弱性開示プログラム(VDP) - 組織が研究者(倫理的ハッカーとも呼ばれます)にセキュリティ脆弱性の報告を要請することで、悪意のある行為者が脆弱性を悪用する前に開示・修正できるようにする仕組み。効果的なVDPには、積極的に脆弱性を探している複数の研究者と、受け取った開示情報を審査・選別する組織内のアナリストのほか、サイバーセキュリティについての知識が豊富で、脆弱性の修正プログラムを作成・展開できるエンジニアが必要です。

脆弱性スキャン - ソフトウェアを使用してサーバー、ネットワークおよびアプリの脆弱性を探すための手法。脆弱性スキャンは、侵入テストに比べて低コストで実行できるため、たびたび(毎月、毎四半期など)実行できますが、侵入テストでは通常、熟練者が厳密に自動化された手法では再現困難な分析スキルや直感を駆使してテストを実施するため、脆弱性スキャンでは見逃される脆弱性を見つけることができます。ネットワークスキャンも参照してください。

W

ウェブアプリ - ウェブアプリは、ブラウザー内で実行されるプログラムで、HTMLドキュメント、JavaScriptコード、動画やその他のメディア、スタイル設定のためのCSSなどのリソースで構成されています。アプリストアから携帯電話にインストールされるモバイルアプリとは対象的に、ウェブアプリは、ブラウザーを使用してリモートサーバーから簡単に取得することができ、インストールの必要がありません。