資料安全規定

以下資料安全規定與 2023 年數據保護評估相應。

請查看此頁面以了解 2024 年 2 月後收到的評估版本。

發生錯誤

播放此影片時發生問題。

可從 Meta 存取特定類型平台資料的應用程式需要完成年度數據保護評估（Data Protection Assessment，DPA）。DPA 旨在確定開發人員在使用、分享和保護平台資料方面是否符合 Meta《開放平台使用條款》的規定。DPA 問卷的其中一部分主要探討《開放平台使用條款》第 6 條，其中概述了資料安全相關規定。我們建議您參閱本文件，了解在使用和處理資料方面的預期、規定和相關證據（如 Meta《開放平台使用條款》所定義），以保障資料安全。

請注意，本文件結尾處附有詞彙表，當中包含重要字詞和定義。

歡迎前往 Data Protocol，查看更多影片資源。

在這份文件中，伺服器端一詞是用以簡稱機構用來處理平台資料的任何後端環境，不論是在 Amazon Web Services（AWS）等雲端主機上執行、由開發人員在共用或專屬資料中心代管，還是採用兩者並用的混合形式亦然。

用戶端規定是指在瀏覽器、流動裝置、桌面版和手提電腦版應用程式，以及用戶所使用其他類型的裝置內處理平台資料。

準備回答資料安全問題

資料流程

建立（或在必要時更新）資料流程圖表或說明，展示應用程式或系統處理平台資料的方式。

用戶端 - 加入所有用戶端軟件，例如瀏覽器、流動裝置，以及任何其他支援的裝置類型。
伺服器端 - 加入任何相關的伺服器或雲端環境，並找出：

所含平台資料符合以下條件的元件：

進出伺服器環境（例如網絡監聽程式和 REST API）
寫入到永久性或耐久性儲存空間，例如資料庫、磁碟或記錄檔案

代管模型，例如：

自我代管 - 機構在自有或共用資料中心運行的自有伺服器。
基礎架構即服務（IaaS）- 例如 AWS EC2、Microsoft Azure IaaS 和 Google Compute Engine。
平台即服務（PaaS）- 例如 AWS Elastic Beanstalk、Google App Engine、Force.com。
後端即服務（BaaS）- 例如 AWS Amplify、Azure Mobile Apps、Firebase 和 MongoDB Switch。
混合型 - 上述模型的組合。

總而言之，資料流程圖表或說明應包含：

產生並傳輸／儲存／更新 Meta API 存取憑證的位置，用戶端和伺服器軟件都包含在內（如適用於系統設計）
從 Meta API 擷取平台資料的方式，重點特別放在個人識別資料，例如用戶的姓名、電郵地址、性別、生日和其他資料
您使用、儲存和傳輸這項資料的方式
所有接收平台資料的第四方

準備證據

您可能必須提出證據，在回答與您導入的資料安全保護措施相關的問題後作為佐證。建議您閱讀本文件中的證據指南來查看可接受的證據範例，並據此準備證據。我們接受常見的文件檔案類型，以及螢幕截圖和螢幕錄影。請確認檔案沒有密碼保護。您可以上載多個檔案，每個最大 2 GB。我們接受 .xls、.xlsx、.csv、.doc、.docx、.pdf、.txt、.jpeg、.jpg、.png、.ppt、.pptx、.mov、.mp4、.zip 和 .zipx。

請務必先編輯（移除）證據中的敏感資料再提出。

證據類型

對於必須上載資料安全保護措施相關證據的應用程式，Meta 要求提供兩種文件：

政策或程序證據 - 政策或程序文件，用以說明 [這項保護措施] 的資料安全做法
導入證據 - 系統或應用程式中的證據，例如工具設定或螢幕截圖，用以證明您已導入特定保護措施

政策或程序證據

政策或程序證據（有時又稱為行政管制）是一種書面文件，用以說明特定資料安全措施的做法。這類證據的形式沒有一定 – 可以是一套內部政策的節錄內容、部分或所有的內部維基網頁，或是在您沒有任何預存文件的情況下，用以說明做法的新建文件。不論如何，您上載的政策或程序證據必須清楚說明與 Meta 規定相關的特定保護措施採取哪種做法。請只提供 Meta 安全審查所需或與之相關的政策或語言，或是使用與該問題相關的任意文字框，將審查人員帶往相關部分。

導入證據

導入證據會直接透過螢幕截圖或螢幕錄影的方式，展現您實際導入政策或程序的做法。由於不同的開發人員有不同的設定，我們無法針對各種情況提供範例。換言之，導入證據所展現的詳細程度，必須盡可能與我們提供的範例相同。

證據完整性

我們了解，要準備導入證據來全面展示特定資料安全保護措施的導入方式，可能會造成過重負擔。有鑑於此，建議您按照這裡的指南提出證據，小心修改證據中的敏感資訊，完成後再提出：

政策或程序證據必須明顯符合或超乎 Meta 的規定

Meta 會審查政策或程序證據，看看當中的陳述是否與 Meta 對特定保護措施的規定一致。
建議您為文件加註，以便標明相關部分
以「為傳輸平台資料時使用的所有網絡連線啟用 TLS 1.2 或更高層級的加密機制」這項保護措施為例，可接受的證據應加入文件來清楚指出：

Meta 平台資料絕不會在未經加密的形式下，透過不可靠的網絡傳輸
凡是用以接收或回傳平台資料的網絡監聽程式（例如面向互聯網的負載平衡器），都會設為啟用 TLS 1.2
凡是用以接收或回傳平台資料的網絡監聽程式，都會設為停用：SSL 第 2 版、SSL 第 3 版、TLS 1.0 和 TLS 1.1

導入證據必須展示各種政策或程序導入方式的一個或多個範例

您必須上載一份或多份文件、螢幕截圖或工具設定，以展現您導入各項保護措施的方式。
Meta 會審查導入證據，確認是否與政策或程序證據一致。
以「為傳輸平台資料時使用的所有網絡連線啟用 TLS 1.2 或更高層級的加密機制」這項保護措施為例，可接受的證據應加入 Qualys SSL 測試報告，證明其中一個網域已按照政策或程序完成設定。

您應該在證據中編輯的敏感資料

提出的證據不得含有以可閱讀（未經編輯）形式提供的任何這些值。如果您要使用圖像編輯器來處理螢幕截圖，請將黑色方框覆蓋在值上方。如果您要使用 PDF 編輯器，請務必編輯文字，使用工具來確實移除這些值，而不是只加上一個圖層卻保留文字（例如 Apple Preview 應用程式中的編輯工具）。

健康資料
財務資料
IP 位址
密碼、憑證和存取憑證
加密金鑰
實體地址
自然人（不含公司或其他企業組織）、員工或其他聯盟的相關個人識別資訊；這些資訊可直接或間接識別該人的身分，例如：
- 姓名
- 電郵地址
- 用戶編號
- 出生日期
- 位置資料
- 健康資料
- 文化、社會、政治身分
- 以專指證據的情況而論，另可用於識別個人身分的資料
安全漏洞的詳細重現步驟（例如在穿透測試報告中）
開發人員知道（或在合理情況下應知道）來自未滿 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 儲存在伺服器端

如果您在即時遊戲 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

請參閱 Microsoft 在 Azure 中的「待用資料加密」說明文件，其主題與機構如何使用其服務相關。

Google Cloud Platform

請參閱 Google 在 Google Cloud Platform 上的「待用資料加密」說明文件。

可接受的替代保護措施

如果您不是在伺服器端環境中導入「待用資料加密」功能，可以透過仍可接受的替代方式保護平台資料。此時，您應該說明：

平台資料的敏感性 - 儲存特定平台資料屬於低還是高風險行為。您必須研究用戶歸因的哪些特定平台資料是儲存在伺服器端。
為了降低發生特定傷害的可能性而套用的控制選項

用於防止內含平台資料的網絡被入侵的控制選項
用於防止可存取平台資料的應用程式／系統被入侵的控制選項
用於防止內含平台資料的實體儲存媒體（例如退役的網絡儲存裝置）損失資料的控制選項
用於防止內含平台資料的實體儲存媒體（例如退役的網絡儲存裝置）損失資料的控制選項
用於防止他人擅自存取內含平台資料備份檔的備份副本的控制選項

證據強度 - 請務必註明這些保護措施是否已經過獨立稽核人員評估（例如在 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 和任何裝置、伺服器或雲端基礎架構	不在資料保護評量的範圍內 - 這類傳輸作業的 TLS 政策是由 Meta 控管

證據指南

如果您必須為這項保護措施提出證據，請按照「準備證據」中的指示同時準備政策／程序和導入證據。如要製作導入證據來證明已設定其中一個網絡監聽程式，最簡單的方法就是使用 Qualys SSL Server Test 工具。

針對以相同方式設定的一個或多個網絡監聽程式（包括所有在非標準連接埠執行的網絡監聽程式），執行 Qualys SSL Server Test 工具。
點擊「Do not show the results on the boards」（不要在面板上顯示結果）選項，以免結果加到 Qualys 網站中。以 PDF 格式列印整個測試結果頁面針對所有您要作為平台資料傳輸目的地／來源，且使用了另一種 TLS 設定的網絡監聽程式重複上述步驟

導入證據範例

此為 Qualys SSL Server Test 工具的結果範例。記下「設定」區塊中的紅色註解，這個區塊總結了支援的 SSL/TLS 版本有哪些。注意：本例只納入前兩頁，但您應該納入整個測試結果。

可接受的替代保護措施

您可使用 TLS 以外的另一種加密功能來保護傳輸中的平台資料；只要該做法提供同等的保護力，您就可以使用。在本例中，您應該提交詳細資料來說明使用的加密功能，以利 Meta 審查：

是對稱還是非對稱加密功能？
加密演算法（例如 AES、BitLocker、TDES、RSA）為何？
密鑰長度下限是多少？

測試應用程式與系統以查看是否有漏洞和安全性問題

問題：您是否有至少每 12 個月測試一次應用程式和系統，看看是否有漏洞和安全性問題？（例如您是否有執行手動滲透測試？）

目的

開發人員必須進行測試以查看是否可主動找到漏洞和安全性問題，從而在理想狀態下防範安全性事件於未然

在 Meta 平台上通過自己配置和操作的應用程式／系統編寫的軟件來處理平台資料的應用程式開發人員
軟件和系統配置可能會含有不肖人士可利用的安全性漏洞，導致平台資料遭到未經授權的存取

規定摘要

適用於所有開發人員：

您必須執行下列任何一項操作，以測試處理平台資料的軟件是否含有安全性漏洞：
- 對應用程式／系統進行滲透測試；或
- 對軟件進行漏洞掃描／靜態分析
測試結果必須顯示沒有任何未解決的重大或高度嚴重性漏洞
測試必須是在過去 12 個月內完成

適用處理平台資料伺服器端的開發人員的附加規定：

您必須執行下列任何一項操作，以特地測試伺服器端軟件是否含有安全性漏洞：
- 對應用程式／系統進行滲透測試；或
- 進行漏洞掃描／靜態分析。如果您有使用雲端代管供應商，則必須對雲端配置進行安全性測試，無論採用哪一種代管方法（例如，BaaS、PaaS、IaaS、IAAS、自我代管或混合方式），該規定都適用。

如果機構正在考慮將 SAST 添加到開發過程中，您可以參考 NIST 維護的開源和商業工具清單，或許可在其中找到適用的工具。

證據指南

如果您必須為這項保護措施提出證據，請按照「準備證據」中的指示同時準備政策／程序和導入證據。

如果機構是在雲端／伺服器環境中處理平台資料：

提交證據以證明您已完成滲透測試或 SAST 工具執行。證據應包括：
- 測試範圍的聲明
- 完成測試的日期，日期應落在過去 12 個月內
- 測試期間發現的漏洞的摘要或清單。摘要或清單必須提供嚴重性分類（例如：重大、高、中、低、資訊型）。一般來說，我們會預期沒有任何未解決的重大或高嚴重性漏洞

您用於處理平台資料的網絡雲端或伺服器軟件（例如，網站或流動客戶端使用的 REST API）必須在此測試的範圍內，我們才會接受此測試結果。

如果適用（即如果您使用的是諸如 AWS、GCP、Azure 或類似的雲端代管服務），請提交證據以證明雲端配置已經過審查，例如 NCC Scout Suite、AWS Config 或類似的運行輸出資料。如果這不適用於機構，請在證據提交中以文件說明雲端配置審查不適用的原因。
在提交證據之前，請從證據中刪除或編輯敏感資訊，例如詳細的漏洞複製步驟

如果機構「不是」在雲端／伺服器環境中處理平台資料：

提交證據以證明您已完成滲透測試或 SAST 工具執行。證據應包括：
- 測試範圍的聲明
- 完成測試的日期，日期應落在過去 12 個月內
- 測試期間發現的漏洞的摘要或清單。摘要或清單必須提供嚴重性分類（例如：重大、高、中、低、資訊型）。一般來說，我們會預期沒有任何未解決的重大或高度嚴重性漏洞。
在提交證據之前，請從證據中刪除或編輯敏感資訊，例如詳細的漏洞複製步驟

證據範例

滲透測試：機構委託對其運行於伺服器端的軟件進行滲透測試，該伺服器已整合 Meta API 並負責處理平台資料。測試公司完成測試並生成如下的摘要信函。請注意紅色註釋，其中顯示了執行測試的日期（必須在過去 12 個月內），且測試（或重新測試，如適用）結果中含有未解決的嚴重／高度嚴重性發現的摘要。在提交報告之前，請從報告中編輯敏感資訊（特別是任何詳細的漏洞複製步驟）。

靜態分析：如果是使用其他方法，例如 SAST 工具，請將結果導出到含有 SAST 運行日期的文件中，並提供含有各種發現類型及其嚴重性的發現清單。

雲端配置審查

使用 NCC Scout Suite 的開發人員會使用其雲端供應商（本例為 AWS）的預設規則來檢查其雲端配置是否存在漏洞和安全性問題。該工具會輸出內含詳細執行結果 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"}]}'

[]

可接受的替代保護措施

如果您正在運行有效的「漏洞披露計劃」（VDP），例如，使用 BugCrowd 或 HackerOne 平台，您可以出示此資訊作為替代保護措施，以取代滲透測試或漏洞掃描。為了展示這一點，您必須提交證據以證明：

與您處理平台資料的方式相關的 VDP 範圍沒有例外
過去 12 個月內有實際進行的漏洞研究和報告，通常每月至少會有 1 份有效的漏洞報告
提交的（有效的）漏洞已分配一個嚴重性分數，例如使用 CVSS 3.1
漏洞在合理的時間範圍內得到解決，通常在提交日期後不到 90 天

在這種情況下，證據應包括：

範圍聲明及其與用於處理平台資料的軟件的關係
以及該計劃在過去 12 個月內提交的實際漏洞報告。報告應包括漏洞標題、提交日期、解決日期（如果已解決）和嚴重性類別／分數。

保護 Meta 應用程式密鑰和 API 存取憑證

問題：Meta API 存取憑證和應用程式密鑰是否同時受到下列兩種保護？

絕不會將 Meta API 存取憑證儲存在非目前應用程式和用戶可存取這項資訊的裝置上。
運用資料倉儲技術（例如 Hashicorp 的 Vault）和獨立密鑰管理服務（KMS），前提是這類存取憑證儲存在雲端、伺服器或資料中心環境。

目的

Meta API 會決定允許哪些動作，這方面的安全性奠基於應用程式密鑰和存取憑證。如果未經授權的一方取得了這些憑證的存取權，他們可能會調用 Meta API（冒充真正的開發人員），並採取我們已授權應用程式執行的任何動作（例如讀取 Meta API 中的應用程式用戶資料）。

您可在使用 Meta 平台時存取敏感憑證，這具體而言是指：
- 存取憑證 - 用戶授權應用程式時，軟件會取得某項憑證，也就是後續進行 API 調用時使用的存取憑證。
- 應用程式密鑰 - Meta 會將應用程式密鑰分享給開發人員，認為機構內只有受信任方（例如應用程式管理員）可存取這個密鑰
如果未經授權方可讀取這類敏感憑證，就能冒充您的身分使用這類憑證調用 Meta API（這有時稱為憑證假冒），導致平台資料受到未經授權的存取
因此，這類憑證必須無法受到未經授權的存取，以防假冒問題發生

規定摘要

存取憑證

在用戶端裝置上 - Meta 存取憑證不得寫入，使得其他用戶或程序可以讀取該憑證。
伺服器端 - 如果您是在伺服器端處理或儲存 Meta 存取憑證，則這類存取憑證：

必須受到資料倉儲技術（例如 Hashicorp 的 Vault）和獨立密鑰管理服務（KMS）的保護，且只有應用程式才能存取解密密鑰
不得寫入到記錄檔案

應用程式密鑰 - 以下兩種情況必須有一種成立：

您從未經應用程式密鑰洩漏到安全伺服器環境外部（例如從未由網絡調用回傳到瀏覽器或流動應用程式，且密鑰未嵌入到發佈至流動或原生／桌面用戶端的程式碼）
您必定已將應用程式設為「原生／桌面」類型，導致 Meta API 不再信任內含應用程式密鑰的 API 調用

證據指南

如果您必須為這項保護措施提出證據，請按照「準備證據」中的指示同時準備政策／程序和導入證據。

加入文件來說明 Meta API 存取憑證和應用程式密鑰保護政策（如果該應用程式在伺服器端處理 Meta 存取憑證），包括提出證據來證明您採取的保護措施（例如使用倉儲技術、證明值已使用加密格式儲存、應用程式的設定要求應用程式密鑰證明）。

請務必不要在您提出的證據中加入（或移除）任何密鑰或存取憑證的純文字值。

證據範例

機構使用 AWS Secrets Manager 妥善保管敏感資料，包括 Meta 應用程式密鑰。

機構已將其 Meta 應用程式設為針對 API 調用要求應用程式密鑰證明。

可接受的替代保護措施

如果您沒有使用資料倉儲技術或透過應用程式級別加密機制，保護儲存在伺服器端的存取憑證，您可以：

使用資料倉儲技術，或只有應用程式才能存取密鑰的應用程式級別加密機制，來保護應用程式密鑰
將應用程式設為針對 API 對 Meta 的所有調用要求應用程式密鑰證明

如果上述第一種做法不可行（例如因為要求應用程式密鑰可能會封鎖特定必要的 API 調用而無法這樣做），Meta 就會考慮您設置用於使存取憑證不易遭擅用（相較於已儲存的存取憑證遭濫用的風險）的任何其他管控措施

設置事件回應計劃並測試事件回應系統和程序

問題：您是否至少每 12 個月測試一次用於回應安全性事件（例如資料外洩或網絡攻擊）的系統和程序？

目的

所有公司都遲早會發生安全性事件，因此機構必須預先做好規劃，決定各項工作的負責人，以便控制住這類事件、與相關利害人士溝通、進行復原工作，並從歷史中學習教訓。

一旦發生安全性事件，如果能事先與受過相關訓練的人員團隊一起做好規劃或擬定策略，就可以縮短該事件的持續時間，進而降低平台資料洩漏的程度
雖然事件回應的縝密度會因機構而異，但我們要求至少必須制定一項包含密鑰活動的基本計劃來進行偵測、回應、復原和審查工作，並為具名人員指派職務和責任

規定摘要

開發人員必須具備：

符合 Meta 最低條件的事件回應計劃。
這份文件必須（至少）包含：(1) 職務和責任、(2) 偵測方式、(3) 根據適用法律和義務採取的回應措施（例如對相關監管機構和資料當事人的資料外洩通知）和復原措施，以及 (4) 帖子事件審查程序
該項計劃最近（過去 12 個月內）經過測試，且計劃中列名的所有人員皆有參與的記載證據。

不論您是否在伺服器端處理平台資料，這項規定都適用。

證據指南

按照「準備證據」中的指示同時準備政策／程序和導入證據。

提交事件回應計劃（一份或多分文件），當中加入下列主題：職務和責任、偵測、回應和復原，以及帖子事件審查
- 如果您沒有事件回應計劃，網絡上有許多資源可供參考，例如 Counteractive 的事件回應計劃範本以及參考資料和額外讀物
提出你在過去 12 個月已測試該計劃的證據。這項證據可以有多種形式，但必須包含：
- 情境說明（例如回應勒索軟件攻擊的桌上演練）、
- 測試日期
- 每位參與者的職務，以及
- 如有列名在計劃「職務和責任」部分中的人員並未實際參與，請個別說明理由
請先修改這項證據中的敏感資訊（例如個人識別資訊，包括個人的姓名和電郵地址）再提出證據範例

事件回應計劃

開發人員根據這個範本建立了全方位的事件回應計劃。這些圖像描繪的只是目錄，但下方有完整範本的連結。

查看完整的 Counteractive 事件回應計劃範本（docx 格式）

事件回應測試

開發人員透過桌上演練測試了事件回應計劃，並根據這個範本記載了結果。

這裡只納入前兩頁，但您必須提交整份文件。

要求完成多重驗證來取得遙距存取權

問題：對於每個能連線至雲端或伺服器環境，且／或能存取您部署、維護、監察及運作 Meta 平台資料儲存系統時所用服務的帳戶，您是否要求完成多重驗證？

目的

對手取得機密資料存取權時常用的技巧，是先針對開發人員用於建立或運作其應用程式／系統的工具取得存取權。某些設計精密的工具可用於駭入只有密碼保護的帳戶；多重驗證可以提高安全性，有助於避開這項風險。

軟件開發人員會使用各式各樣的工具，來建立、部署和管理他們的應用程式／系統
這些工具經常會透過互聯網遙距使用（例如員工在家上班並推出新的軟件功能，或是更新雲端設定）
使用單一驗證機制（用戶名稱和密碼）保護的工具，很有可能會遭受帳戶接管攻擊。舉例來說，攻擊者可能會使用多項工具，嘗試以其中一項工具所洩漏出的用戶名稱和密碼組合存取另一項工具
多重驗證則會在用戶登入時要求輸入密碼以外的另一項資訊（例如驗證應用程式所產生的代碼），以防遭受上述攻擊

規定摘要

機構在處理平台資料時，必須以多重驗證（亦即不只使用密碼）來保護這些工具的遙距存取權：

用於部署和管理應用程式／系統程式碼或設定變更的工具
雲端或伺服器環境的管理員存取權（如適用）

具體而言，下列項目需要採用 MFA 或可接受的替代保護措施：

協作／通訊工具 - 例如企業電郵信箱或 Slack
程式碼存放庫 - 例如 GitHub，或是其他用於追蹤應用程式／系統程式碼或設定變更的工具
如果是在伺服器端處理平台資料：
- 軟件部署工具 - 用於將程式碼部署到雲端／伺服器環境中的工具，例如 Jenkins 或其他連續整合／連續部署（CI／CD）工具
- 管理工具 - 入口網站或其他存取權，用於管理／監察雲端或伺服器環境
- 伺服器遙距存取權 - SSH、遙距桌面或類似工具，用於遙距登入在伺服器端運作的伺服器

關於 MFA 的導入方式：

建議使用驗證應用程式或硬件（例如 YubiKey）處理透過短訊傳送的代碼
但組織可使用任何 MFA 導入方式

證據指南

如果您必須為這項保護措施提出證據，請按照「準備證據」中的指示同時準備政策／程序和導入證據。

導入證據必須證明適用於上述環境的工具上（例如協作工具、程式碼存放庫、雲端／伺服器部署、雲端／伺服器行政入口網站、雲端／伺服器遙距存取權）已強制執行 MFA
導入方式會因設定而異：
- 舉例來說，如果您使用的是 SSO 供應商，這類證據可以是機構全域設定的螢幕截圖，或是個別應用程式設定的螢幕截圖。
- 如果您沒有 SSO 供應商，這類證據可以是特定工具設定的螢幕截圖
不論如何，我們都需要有證據來證明對所有用戶皆已啟用 MFA，而不是只例舉某個已啟用 MFA 的帳戶

證據範例

AzureAD

機構使用 AzureAD 作為單一登入解決方案。這項政策要求完成多重驗證。

政策隨後對應至其套用的雲端應用程式。如果採用這種做法，證據必須列出「所選項目」區塊，明示哪些雲端應用程式需要完成 MFA。

Okta

這項規定要求所有登入都必須完成 MFA。

AWS IAM

這是其中一種 AWS IAM 政策，用以允許 MFA 設定但禁止其他動作（如果沒有 MFA）。

GitHub

機構已將 GitHub 驗證設為針對機構內的所有人要求完成 MFA。

可接受的替代保護措施

對於任何一種存在於機構內但未強制執行 MFA 的遙距存取權，您都必須說明是否採用了上述任何一種或多種做法來防止帳戶被盜用：
- 強效密碼要求 - 例如最低的密碼複雜度、禁用字典詞彙、禁用已知曾外洩的密碼
- 驗證倒退 - 使用工具在同一來源兩次登入失敗之間導入越來越長的等候期間
- 自動鎖定 - 例如在帳戶登入失敗 10 次後自動禁止再登入的機制

設置系統來維護用戶帳戶

問題：您是否設置系統來維護帳戶（指派、撤銷、審查存取權和其他權限）？

目的

想要避免他人擅自使用帳戶來取得平台資料的存取權，就必須養成良好的帳戶管理習慣。特別是，如果有不再需要使用的資源或系統，開發人員必須撤銷其存取權。

帳戶是基本管理單位，可讓用戶存取系統、資料和管理員功能
帳戶會取得執行特定動作的權限；建議您只授予帳戶所需的最低權限，也就是所謂的最低權限原則
如果有人從機構離職，他們的用戶帳戶就必須立即被停用，原因則有幾個：
- (1) 防止此人（亦即前任員工）存取資料，以及
- (2) 降低未經授權者在無人發現的情況下使用帳戶的可能性。舉例來說，不肖人士可能會利用社交工程技術，造成 IT 服務台重設帳戶密碼。如果帳戶為現任員工所有，該員工可能會回報自己無法登入的問題，而要是帳戶仍然有效但為離職員工所有，這個問題就不太可能會被注意到。
有鑑於此，機構必須透過系統化的方式管理帳戶、授予權限，以及撤銷不再需要的存取權

規定摘要

您必須擁有為上述個別工具／系統／應用程式管理帳戶的工具或程序：
- 用於與彼此通訊的工具／系統／應用程式，例如 Slack 或企業電郵信箱
- 用於推出軟件的工具／系統／應用程式，例如程式碼存放區，以及
- 管理並運作系統（適用於處理平台資料）
您必須定期審查（例如每 12 個月不少於一次）存取權授予情形，並建立在以下時機撤銷存取權的程序：(1) 不再需要該存取權，以及 (2) 不再使用該存取權
此外，您也必須建立程序，以便在有人離開機構時立即撤銷對這些工具的存取權
Meta 不會要求
- 使用任何特定工具 – 開發人員可使用 Google Cloud Identity 或 Microsoft Azure Active Directory（類似於 AWS 身分和存取權管理（IAM）的雲端產品），也可以使用定期更新的試算表。
- 有合而為一的工具可跨多種存取權管理帳戶。

不論您是否在伺服器端處理平台資料，這項規定都適用。

證據指南

按照「準備證據」中的指示同時準備政策／程序和導入證據。

政策／程序 - 提供記載的政策和程序文件，當中涵蓋帳戶管理做法。這份文件應包含帳戶建立程序、授權程序、最低密碼複雜程度、帳戶鎖定政策、MFA 政策、帳戶重設程序，以及在閒置一段時間或員工離開組織（例如員工辭職或被開除）後撤銷存取權的程序。
導入證據 - 透過下列至少一項設置用於管理帳戶（或代表不適用於該環境）的工具或程序來提供證據：(1) 商業電郵和協作工具、(2) 程式碼存放區、(3) 雲端／伺服器部署工具、(4) 雲端／伺服器行政入口網站、(5) 雲端／伺服器遙距登入（例如 SSH 或遙距桌面）。如需具代表性的不同工具或程序，請加入證據來證明：
- 已離開機構的人員對這些工具的存取權被撤銷（例如比較用戶帳戶和目前機構成員授權資料的對帳報告）
- 已閒置一段時間的存取權會被撤銷，例如報告顯示代表性有效用戶帳戶持有人的上次存取日期在過去 90 天內（如果最長閒置期間為三個月）

證據範例

政策／程序 - 某開發人員建立了存取權生命週期管理標準，包括用於授予、查看和撤銷存取權的程序。

導入範例 - 已離職人員的存取權會被撤銷

開發人員使用 Workday 作為人力資源（HR）資料的授權來源，包括目前的聘僱狀態。這位開發人員使用 Google Cloud Identity 做為身分識別服務供應商（IdP），以便管理用戶帳戶並授予存取權給資訊系統和工具。

開發人員透過下列方式提出證據，證明離職人員的存取權已被撤銷：在提交的報告中指出，最近（例如過去 12 個月內）在執行對帳報告後發現，根據 Workday 現有員工報告不算是有效員工的人員，在 Google Cloud Identity 中已無有效的用戶帳戶。

導入範例 - 不再使用的存取權會被撤銷

開發人員使用 Google Cloud Identity 做為身分識別服務供應商（IdP），以便管理用戶帳戶並授予存取權給資訊系統和工具。

開發人員透過下列方式提出證據，證明不再使用（例如過去 6 個月沒有登入活動）的存取權已被撤銷：提交按上次登入時間排序的用戶目錄作為證據，證明在上次登入比這次更早的情況下，已無有效的用戶帳戶。

導入範例 - GitHub（程式碼存放區）

開發人員使用單一登入（SSO）工具來管理身分，並授予存取權給資訊系統和工具。該開發人員已將 GitHub 設為要求 SSO 驗證。

持續更新軟件

問題：您是否設置系統來持續更新系統程式碼和環境，包括伺服器、虛擬機器、流通渠道、程式庫、套件和防毒軟件？

目的

軟件元件會定期更新或修補來解決安全性漏洞，最終在不再受支援時壽終正寢。包裝或採用這些元件的開發人員必須隨時掌握最新狀況，以免執行的軟件出現已知漏洞。

應用程式開發人員會採用多種第三方軟件，來執行用於處理平台資料的應用程式／系統
舉例來說，開發人員會採用部分或所有的：
- 程式庫、SDK、套件 - 開發人員會使用自己的自訂程式碼包裝這些項目來建立應用程式
- 虛擬機器映像、應用程式容器和作業系統 - 應用程式會在一個或多個這類容器中執行，而這些容器則會提供虛擬化以及網絡和儲存空間存取權等服務
- 瀏覽器、作業系統，以及其他由員工／協作者使用的應用程式 - 在流動裝置和手提電腦上執行，且由開發人員用於建立並執行系統的軟件
安全性漏洞經常出現在這些元件中，修補檔案也就因此推出
修補檔案所修正的漏洞屆時會在公開資料庫中披露，並附上嚴重性評分（低、中、高或重大）
因此，Meta 平台上的開發人員必須透過系統化的方式管理修補檔案，例如：
- 找出與其應用程式／系統相關的修補檔案
- 根據曝光程度優先處理緊急項目，以及
- 將修補檔案視為持續進行的業務活動來套用

規定摘要

對於下列軟件元件，您必須視乎情況透過可重複的指定方式，找出可用修補檔案來解決安全性漏洞，並根據風險等級決定優先順序，同時將修補檔案視為持續活動來套用：

用於雲端或伺服器環境的程式庫、SDK、套件、應用程式容器和作業系統
用於用戶端裝置（例如流動應用程式內）的程式庫、SDK 和套件
成員用於建立並運作應用程式／系統的作業系統和應用程式，例如在員工手提電腦上執行的作業系統和瀏覽器

Meta 並不要求針對這些活動使用任何特定工具。機構通常會使用不同的做法持續更新各種軟件（例如以員工手提電腦的應用程式或作業系統更新內容包裝的程式庫）。

不論代管做法為何（例如 BaaS、PaaS、IaaS、自我代管或混合式），這項規定都適用，但您負責持續更新的元件組合會有所不同

下方圖表顯示各種架構類型可能需要修補檔案的情形。

證據指南

如果您必須為這項保護措施提出證據，請按照「準備證據」中的指示同時準備政策／程序和導入證據。

先找出環境中範圍內的軟件類型，例如程式庫、SDK、套件、虛擬機器映像、應用程式容器、作業系統、瀏覽器，以及員工／協作者使用的其他應用程式。

您可以有一項或多項用於下列活動的工具：

盤點 - 透過螢幕截圖或文件記載某工具或程序最終代表範圍內需要修補的程式庫、套件、SDK、容器、應用程式伺服器和作業系統清單。軟件類型（例如雲端應用程式、用戶端應用程式、員工裝置）的代表必須有盤點。
找出可用的軟件修補檔案 - 必須要有工具或程序來找出與盤點相關的現有安全修補檔案。
決定優先順序 - 必須要有相關修補檔案用以指定優先順序的工具或程序（例如 Jira 票證、GitHub 問題、追蹤試算表）
- 修補
- 透過螢幕截圖或文件記載的方式，證明在找出相關修補檔案並決定優先順序後，修補檔案已在不同目的地推出。
加入與解決時間和使用「產品壽命結束」（EOL）軟件相關的政策。

證據範例

NodeJS 應用程式的 Snyk - 開發人員使用 Synk 指令行介面（CLI）找出有已知安全性漏洞的套件式第三方相依性，並根據這些漏洞的嚴重性決定優先順序。

NPM 稽核

開發人員使用 NPM 稽核來找出 Node 應用程式所用相依性的漏洞。下方例圖顯示多個必須修補的高嚴重性漏洞。

Trivy

開發人員使用 Trivy 找出機器圖像中的漏洞。下方例圖顯示本圖所附程式庫中多個必須修補的高嚴重性漏洞。

Windows Server Update Services（WSUS）

開發人員使用 Windows Server Update Services（WSUS）管理伺服器和 PC／手提電腦機群。下方例圖顯示 WSUS 工具的管理員檢視畫面，可讓您查看、批准和部署 Windows 更新。

設置系統來記錄對平台資料的存取，並追蹤平台資料的傳送目的地和儲存位置

目的

要是沒有可靠的記錄檔案，開發人員可能就很難偵測未經授權對平台資料的存取。

稽核記錄可讓機構記錄有事件發生，例如特定用戶對含有平台資料的資料庫表格執行了查詢
這類記錄接著便可支援許多程序，例如根據可疑活動觸發自動警示，或是在發現安全性事件後觸發鑑識分析

規定摘要

如果您是在伺服器端處理平台資料，則在該伺服器環境內：

您應該維護重要事件（例如存取平台資料、配搭升級權限使用帳戶、變更稽核記錄設定）的稽核記錄
多項稽核記錄應合併為一個集中存放區，且禁止修改或刪除

證據指南

如果您必須上載證據，證據必須能證明：

您透過目前的資料流程圖表了解平台資料目前的儲存、存取和轉移方式，這個圖表可顯示系統的大致樣貌、指派服務來儲存平台資料，並顯示出入點，包括如預期轉移資料到所有第四方服務。
您已導入防竄改的稽核記錄
與存取平台資料相關的事件會納入記錄

監察平台資料的轉移，以及平台資料離開系統（例如第三方、公開端點）的重要時間點

目的

組織想要確保平台資料僅用於原定用途，就必須了解平台資料應該會如何處理，然後監察實際的處理方式

開發人員必須即時掌握平台資料儲存、透過網絡傳輸，以及寫入到備份檔案（可複製到其他地方）的方式
舉例來說，監察可找出平台資料以非正常方式傳輸，或者是透過傳輸時沒有適用加密機制的網絡傳輸的情況，方便您採取行動。

規定摘要

如果您是在伺服器端處理平台資料，就應該在該伺服器環境內：

維護準確的資料流程圖表，當中顯示平台資料在不同網絡上的儲存、處理和傳輸方式
針對系統外轉移平台資料的情況設定監察功能（例如自動監察產品的稽核記錄）
如果可以，請將監察系統設為在平台資料異常傳輸的情況下發出立即經過審查的警示（請一併參閱下方規定 - 設置自動化系統來監察記錄和其他安全事件，以及針對異常或安全相關事件產生警示）

證據指南

如果您必須為這項保護措施提出證據，請按照「準備證據」中的指示同時準備政策／程序和導入證據。

您應該要提供證據來證明：

您透過目前的資料流程圖表了解平台資料目前的儲存、存取和轉移方式，這個圖表可顯示系統的大致樣貌、指派服務來儲存平台資料，並顯示出入點，包括如預期轉移資料到所有第四方服務。
已導入防竄改的稽核記錄。
與轉移平台資料相關的事件都會捕捉到事件中；事件應納入時間、用戶或應用程式採取行動的身分，以及來源和目的地。

設置自動化系統來監察記錄和其他安全事件，以及針對異常或安全相關事件產生警示

目的

仰賴人工審查並找出現代可連網系統中的非預期行為，是不切實際的想法。反之，有些工具可擷取記錄檔案和其他訊號，以便提出需要用戶進一步調查的警示。

規定摘要

如果您是在伺服器端處理平台資料，就應該在該伺服器環境內：

使用工具來擷取記錄檔案和其他事件、建立犯錯時發出警示的規則，以及可將警示轉發給其他人（例如待命中的安全調查人員）的機制
將相關訊號擷取到工具中（例如網頁存取記錄、驗證嘗試、具有升級權限的用戶所採取的動作）
隨著時間經過，請調整規則來取得訊號和雜訊之間的平衡（例如避免過多的誤報，同時不忽略需要調查的事件）

證據指南

開發人員通常會將安全資訊與事件管理（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 的雲端運算服務套件

應用程式範圍編號（ASID）：Meta 在人們選擇使用應用程式時所生成的不重複識別資料。ASID 可通過讓資料集更難關聯不同應用程式之間的用戶，藉此幫助改善用戶的私隱，因為使用兩個應用程式的單一用戶在每個應用程式中都會有不同的 ASID。

應用程式密鑰：Meta 通過應用程式管理中心向開發人員提供的共享密鑰。擁有應用程式密鑰即可授權軟件通過 Graph API 執行某些操作，因此開發人員需要注意不要讓未經授權的各方存取應用程式密鑰。

應用程式入侵：如果惡意行為者能夠通過其應用程式中的錯誤配置或漏洞（例如，網絡應用程式中的軟件漏洞）對組織內部網絡進行未經授權的存取，則稱為應用程式入侵。若要防範應用程式入侵，可對應用程式進行滲透測試。另請見網絡入侵。

應用程式容器：容器可以打包軟件代碼和相關依賴項目，讓應用程式可以在不同類型的伺服器上運行（例如，運行 Linux 或 Windows 等不同作業系統的伺服器）。開發人員會建立一個容器映像來打包他們的應用程式。應用程式容器引擎或執行期會代管（運行）容器映像。

應用程式加密：一種保護資料的方法，應用程式軟件本身會執行加密和解密操作。相比之下，當應用程式與遠程伺服器建立安全連線時（例如，使用 HTTPS），以及雲端供應商提供服務以透明化的方式加密靜態資料時，「傳輸層安全性協定」（TLS）就會無縫地加密傳輸中的資料。

應用程式介面（API）：允許兩個電腦通過網絡相互通訊，例如流動應用程式從集中式天氣預報系統獲取某個地點的當日天氣

應用程式密鑰證明：這是 API 傳送調用至 Meta 的額外保護機制，開發人員會生成一個參數（應用程式密鑰證明）以證明他們持有應用程式密鑰。應用程式密鑰證明是根據應用程式密鑰和存取憑證產生的雜湊函數（也稱為單向函數）的產物。將應用程式配置為在調用 Graph API 期間需要應用程式密鑰證明，有助於減少違反用戶存取憑證被入侵的潛在危害，因為如果沒有額外的應用程式密鑰證明參數，就無法使用這些存取憑證。

B

後端即服務（BaaS）：一種雲端運算方式，可為應用程式開發人員提供一套伺服器端功能，讓該開發人員可以專注於構建前端（即用戶使用應用程式的部分）。BaaS 解決方案類似於 PaaS，此外還添加了用戶身分驗證和手機推送通知等服務。舉例來說，這些是一些常見的 BaaS 產品：AWS Amplify、Azure Mobile Apps、Firebase 和 MongoDB Switch。

C

密文：加密資料的同義詞，密文是指通過某種加密算法使資料變得無法讀取的意思。密文的反義詞是明文。

客戶端：人們通常會使用瀏覽器開啟網站，或使用手機或平板電腦執行流動應用程式，藉此與互聯網服務進行互動。瀏覽器或流動應用程式即稱為本地客戶或客戶端。客戶會通過互聯網從遠程電腦（伺服器）發出要求。

雲端運算：指一種管理伺服器電腦、網絡和儲存的方式，讓組織不必擔心物理環境（即配置了許多伺服器機架和網絡電纜的數據中心）。所以，組織可以按需配置這些資產，並為其使用的服務付費即可。

雲端配置：組織針對其使用運行某些軟件的雲端供應商而設置的一組雲端運算選項。雲端配置的範例包括允許或封鎖哪些類型的網絡連線、日誌檔案的寫入位置和保存時間，以及有權更改雲端配置的用戶組別。

補償控制：一種安全性控制，有別於某些基線要求集，但旨在提供類似的風險保護。

D

資料庫：允許儲存、讀取、更新和刪除任意資料的軟件。資料庫可以在客戶端和伺服器上運行。整合 Meta 平台的組織通常會將他們從 Graph API 獲取的資料儲存在運行於伺服器端的資料庫中。

解密：將加密資料轉換回其原始格式的過程。換言之，解密會將密文轉換為明文。

E

加密：將資料轉換為任何無法解密的人都無法使用的格式的過程。換言之，加密會將明文轉換為密文。

靜態加密：寫入持久性儲存（例如硬碟）時受加密保護的資料。靜態加密可提供額外的保護以防止遭到未經授權的存取，因為能夠讀取儲存裝置上的原始檔案的用戶將看到密文並且無法解密，除非他們也取得了解密密鑰。

傳輸中加密：在通過網絡傳輸時受到加密保護的資料。傳輸中加密可提供保護以防止遭到沿網絡路徑竊聽的保護，因為能夠讀取網絡封包的用戶將看到密文並且無法解密，除非他們也取得了解密密鑰。

產品壽命結束（EOL）軟件：當組織選擇停止支援（例如建立補丁以解決安全漏洞問題）某個軟件產品，該軟件就會被視為產品壽命結束。由於組織停止維修該軟件，因此運行任何 EOL 軟件的風險都很大。

G

Google 雲端平台（GCP）：Google 的雲端運算服務套件 Graph API，是應用程式讀取和寫入 Meta 社交關係圖的主要方式。所有 Meta SDK 和產品都會以某種方式與 Graph API 互動。

H

雜湊函數：一種加密函數，可將任何資料輸入和輸出為無法反轉為原始資料的簡短代碼。在密碼學中，雜湊函數是用於保護密碼等資料，而不是以可能被盜的明文儲存用戶的密碼，密碼會先經過雜湊函數的轉換，然後才儲存起來。之後，為了確認用戶輸入了正確的密碼，系統將使用相同的雜湊函數來轉換輸入資料，並將生成的雜湊值與儲存的值進行比較。這也稱為單向函數，因為輸出的雜湊值無法反轉為原始輸入資料。

代管環境：指組織在自己的資料中心或與其他客戶共同代管（或 colo）的資料中心內運行的一組遠程伺服器、網絡和儲存裝置。由於雲端運算變得越來越流行，這種安排現在已經變得較為少見。

I

身分供應商（IdP）：一種雲端服務，用於集中管理數碼身分和驗證用戶身分。使用 IdP 的組織通常會將雲端應用程式配置為依賴 IdP 進行用戶身分驗證。然後，組織便可以通過在 IdP 中集中建立和授權選定應用程式，以及禁用用戶帳戶來管理用戶，而不必在每個雲端應用程式中重複執行此操作。

身分和存取管理（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 與 Graph API 進行通訊）。

多重要素驗證（MFA）：一種身分驗證方法，需要多重要素才能存取應用程式或系統。與僅依賴密碼來驗證用戶身分的單一要素驗證相比，MFA 通常需要密碼外加下列一個或多個項目：通過電郵或短訊發送的代碼、來自身分驗證器應用程式的代碼、生物特徵掃描、或安全密鑰。MFA 能夠讓未經授權的行為者更難強行入侵帳戶，藉此防止帳戶遭到盜用，例如通過使用已知的電郵地址和常見密碼持續嘗試登入帳戶直到成功為止。

N

原生軟件：下載並安裝到手提電腦或流動裝置上的應用程式即稱為原生軟件（例如 iOS 版 Facebook 應用程式）。反之，在瀏覽器中運行的應用程式則稱為網絡應用程式（例如，使用 Chrome 瀏覽器打開 Facebook）。

網絡入侵：如果惡意行為者能夠通過網絡本身的錯誤配置或漏洞對組織內部網絡進行未經授權的存取，則稱為網絡入侵。若要防範網絡入侵，可執行網絡掃描以找出面向互聯網的網絡中的錯誤配置和漏洞。另請參閱應用程式入侵。

網絡掃描：一種使用軟件來執行以下操作的風險管理流程：(1) 識別網絡上可回應遠程通訊的活躍伺服器，然後 (2) 查看這些伺服器中是否有運行任何已知易受一個或多個安全漏洞攻擊的舊版軟件。例如，組織可能會定期使用網絡掃描來確保其網絡外圍沒有未知的開放端口。

Node 套件管理工具（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。

端口：當客戶端通過網絡連接到伺服器時，目的地位址有兩個部分：(1) 伺服器的網絡協定（IP）位址和 (2) 該伺服器上特定應用程式將回應的端口號碼。通用協定會使用保留端口（例如，HTTPS 使用 443），但如果需要，開發人員也可以使用自訂端口進行網絡通訊。

R

REST API：一種廣泛採用的構建網絡存取服務的方式，其中客戶端和伺服器會使用 HTTP 協定進行通訊。Meta 平台上的開發人員可能會在 api.example.com 之類的子網域上代管 REST API，他們的流動應用程式向／從該子網域傳送和接收平台資料。

S

安全外殼協定（SSH）：一種允許管理員遠程登入伺服器並在這些伺服器上運行程序的通訊架構。之所以稱為「安全」，是因為客戶端和伺服器之間的通訊能受到保護而不會被竊聽，有別於 Telnet 等早期協定。另外也稱為安全通訊外殼（Secure Socket Shell）。

安全通訊協定（SSL）：已經過時且不安全的傳輸中加密技術。現代安全版本的技術稱為「傳輸層安全性協定」（TLS）。

伺服器：通過網絡遠程提供服務的電腦。瀏覽器和流動應用程式都是通過網絡連接到伺服器。

無伺服器運算：一種雲端運算方式，其中雲端主機負責管理物理基礎設施、伺服器作業系統和容器。開發人員只需負責自訂代碼和相關函數庫以及雲端配置。

伺服器端：網絡連接另一端（即伺服器上）的資料或運算即稱為伺服器端。反之，本地設備（如手提電腦或流動裝置）上的資料或運算則被稱為客戶端。

單一登入（SSO）：應用程式依賴集中式用戶目錄（即 IdP）對用戶進行身分驗證的一種技術。除了可為組織集中管理用戶帳戶和應用程式存取權限之外，用戶只需使用同一組憑證即可，而不必為每個不同的應用程式維護不同的憑證（例如，用戶名稱和密碼）。

軟件開發套件（SDK）：一種代碼建構組元，開發人員可以使用它來簡化特定需求的開發過程。舉例來說，Meta 建立和維護的 SDK 可以簡化 iOS 和 Android 開發人員使用 Graph API 的作業。類似於函數庫，在其應用程式中使用 SDK 的開發人員需要隨著時間的推移持續更新 SDK。

軟件即服務（SaaS）：允許客戶通過互聯網使用雲端基礎的應用程式。有別於 PaaS 或 IaaS，SaaS 應用程式的客戶不用部署自訂代碼，也不負責配置、升級或修補 SaaS 應用程式，因為所有這些工作都是 SaaS 軟件供應商的責任。舉例來說，這些是一些常見的 SaaS 產品：Dopbox、MailChip、Salesforce、Slack。

靜態分析：請參閱「靜態應用程式安全測試」

靜態應用程式安全測試：一種針對源代碼運行專用工具來尋找軟件漏洞的方法。SAST 工具會識別潛在漏洞，例如 OWASP Top 10 專案中列出的漏洞，然後開發人員負責審查識別結果、區分真假漏洞，最後修復軟件中的漏洞。SAST 很實用，因為它可以讓開發人員在部署到生產環境之前發現漏洞，但有別於滲透測試，SAST 工具無法找到與應用程式的生產配置相關的漏洞。

T

透明資料加密：一種通常應用於資料庫儲存（即資料庫內容本身及其日誌檔案）的靜態加密。在這種安排下，資料庫軟件會管理加密密鑰，並以透明化的方式處理加密操作（寫入時）和解密操作（讀取時）。

傳輸層安全性協定（TLS）：一種傳輸中加密架構，使用加密技術來保護通過網絡傳輸的資料免受網絡路徑上的竊聽者的侵害。TLS 是現代安全版本的技術，過時的早期技術則是 SSL。

雙重驗證（2Fac）：多重要素驗證的同義詞。保險庫：用於加密密鑰、存取憑證和其他憑據等敏感資料的密鑰管理系統。保險庫允許嚴格控制誰能夠存取其中的密鑰，並可提供額外的服務，如保存稽核日誌。

V

虛擬機器（VM）：非常類似於應用程式容器；虛擬機器會在稱為虛擬機器監視器（hypervisor）的主機中運行，而應用程式容器則是在容器引擎中運行。主要區別在於 VM 映像含有作業系統，而應用程式容器則沒有。VM 和應用程式容器都含有應用程式和依賴項目（例如函數庫）。

虛擬私有雲（VPC）：AWS 用來指稱一組雲端資源，類似於雲端出現之前的資料中心內的傳統網絡。

漏洞：系統或應用程式中可能被利用的缺陷，例如讀取行為者無權讀取的資料

漏洞披露計劃（VDP）：組織向研究人員（有時稱為道德黑客）徵求安全漏洞報告的一種方法，以便在惡意行為者利用漏洞之前先行發現並修復。有效的 VDP 需要有一組積極尋找漏洞的研究人員、審查和分類披露報告的組織分析師，以及具備網絡安全知識並且能夠建立和部署漏洞修復程序的工程師。

漏洞掃描：一種使用軟件查找伺服器、網絡和應用程式漏洞的方法。與滲透測試相比，漏洞掃描運行成本較低，因此可以重複運行（例如，每個月或每一季），但滲透測試通常能夠找到漏洞掃描遺漏的漏洞，因為技術高超的滲透測試人員具備分析技能和直覺，而很難用嚴格的自動化方法複製。另請見網絡掃描。

W

網絡應用程式：網絡應用程式是在瀏覽器中運行的程序，由 HTML 文件、JavaScript 代碼、影片和其他媒體，以及用於樣式的 CSS 等資源組成。與人們從應用程式商店安裝到手機上的流動應用程式相比，人們只需使用瀏覽器（例如 www.facebook.com）從遠程伺服器獲取網絡應用程式，而無需安裝步驟。