Data Security Requirements

準備回答資料安全問題

資料流程

建立（或更新，如有必要）可說明應用程式或系統如何處理平台資料的資料流程圖或描述。

1. 用戶端 - 包含所有用戶端軟體，例如瀏覽器、行動裝置，以及任何其他支援的裝置類型。
2. 伺服器端 - 包含任何相關伺服器或雲端環境，並找出下列項目：
1. 平台資料採取下列行動的元件：
1. 進入或離開伺服器環境（例如網路接聽程式或 REST API）
2. 被寫入資料庫、磁碟或紀錄檔案等持續性或耐久性儲存空間
2. 代管模式，例如：
1. 自行代管 - 組織本身的伺服器在自有或共享資料中心運作。
2. 基礎設施即服務（IaaS） - 例如 AWS EC2、Microsoft Azure IaaS 和 Google Compute Engine。
3. 平台即服務（PaaS） - 例如 AWS Elastic Beanstalk、Google App Engine、Force.com。
4. 後端即服務（BaaS） - 例如 AWS Amplify、Azure Mobile Apps、Firebase 和 MongoDB Switch。
5. 複合式 - 上述模式的幾種組合。

最終，資料流程圖或描述應包括：

1. 在用戶端和伺服器端軟體中開發並傳輸／儲存／更新 Meta API 存取權杖的位置（若適用於系統設計）
2. 您從 Meta 的 API 擷取平台資料的方式，特別是針對用戶姓名、電子郵件地址、性別、生日和其他用戶資料等個人識別資料（PII）
3. 您使用、儲存和傳輸此資料的方式
4. 任何接收平台資料的第四方

準備證據

您可能需要提交證據以支援與您實施之資料安全保護相關的答案。我們建議您參閱本文件中的證據指南，以了解可接受證據的範例，並據此準備證據。我們接受常見的文件檔案類型，以及螢幕截圖和螢幕錄影。請確保檔案未受密碼保護。您可以上傳多個檔案，每個檔案大小不超過 2 GB。我們接受 .xls、.xlsx、.csv、.doc、.docx、.pdf、.txt、.jpeg、.jpg、.png、.ppt、.pptx、.mov、.mp4、.zip 和 .zipx。

證據類型

對於系統要求上傳資料安全保護相關證據的應用程式，Meta 需要兩種不同類型的文件：

1. 政策或程序證據 - 說明 [本保護] 資料安全作法的政策或程序文件
2. 實作證據 - 來自系統或應用程式的證據（例如工具配置或螢幕擷取），可顯示您如何實施特定保護

政策或程序證據

政策或程序證據有時稱為管理控制，是說明特定資料安全保護的書面文件。此類證據的形式可能會有所不同 – 也許是一套內部政策的摘錄、部分或全部的內部 Wiki 頁面，或是您用來說明作法的新建文件（如果您沒有任何預先建立的文件）。在任何情況下，您上傳的政策或程序證據都必須明確說明特定保護的作法與 Meta 的條件有何關聯。請僅提供與 Meta 安全審查相關且必要的政策或內容，或使用與問題相關的問答題方塊，以便將審查人員帶往至相關部分。

實作證據

實作證據說明您如何直接透過螢幕截圖或螢幕錄影實際實施政策或程序。由於不同的開發人員有不同的配置，我們無法為每種情況都提供範例。話雖如此，實作證據應盡可能呈現出與我們提供的範例相同的詳細程度。

證據完整性

我們瞭解，要準備可完整展示已實作特定資料安全保護的實作證據，負擔可能過於沉重。考量到這一點，您應該按照此處的指引提交證據，提交前請記得修訂證據中的敏感資料：

1. 政策或程序證據必須明確符合或超過 Meta 的要求
1. Meta 將審查政策或程序證據，以瞭解其陳述是否符合 Meta 對特定保護的要求。
2. 您應註明文件以強調相關部分。
3. 例如，與針對傳輸平台資料之所有網路連線啟用 TLS 1.2 或以上版本加密的保護相關，可接受的證據將包括明確聲明下列事項的文件：
1. 來自 Meta 的平台資料絕不得以未加密的格式在不受信任的網路中傳輸
2. 所有接收或回覆平台資料的網路接聽程式（例如面向網際網路的負載平衡器）都將配置為啟用 TLS 1.2
3. 所有接收或回覆平台資料的網路接聽程式都將配置為停用下列項目：SSL v2、SSL v3、TLS 1.0 和 TLS 1.1
2. 實作證據必須展示每項政策或程序實作的一個或多個範例
1. 您必須上傳一個或多個可展示出您如何實作每項保護的文件、螢幕截圖或工具配置
2. Meta 將審查實作證據，以確保其符合政策或程序證據
3. 例如，與針對傳輸平台資料之所有網路連線啟用 TLS 1.2 或以上版本加密的保護相關，可接受的證據將包括其中一個網域進行的 Qualys SSL 測試報告；該網域係根據政策或程序配置。

您應從證據中修訂的敏感資料

請勿以可讀取（未修訂）的形式提交包含任何下列數值的證據。如果您使用圖像編輯器進行螢幕截圖，請在數值上方疊壓黑色方塊。如果您使用 PDF 編輯器，請確保用來修訂文字的工具可確實移除數值，而不只是單純加入圖層並保留文字（例如 Apple「預覽程式」應用程式中的修訂工具）。

• 健康資料
• 財務資料
• IP 位址
• 密碼、憑證和存取權杖
• 加密金鑰
• 實體地址
• 與自然人（不包括商家或其他企業組織）、員工或其他子公司相關、並可直接或間接識別該個人的個人識別資訊（PII）

  • 姓名
  • 電子郵件地址
  • 用戶編號
  • 出生日期
  • 地點資料
  • 健康資料
  • 文化、社會、政治身分
  • 在證據的特定背景資訊下，可透過其他方式識別個人的資料
• 詳細的漏洞重現步驟（例如來自滲透測試的資料）
• 開發人員知道或理應知道係來自或有關 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 在伺服器端儲存資料

若您只透過 Meta API（例如使用 player.setDataAsync()）在即時遊戲 SDK 中儲存平台資料，則此問題不適用。

證據指南

如果系統要求您提交此保護措施的證據，請按照準備證據中的指示操作，準備政策／程序和實作證據。

實作證據範例

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 資料加密說明文件，瞭解組織如何使用 Microsoft 的服務。

Google Cloud Platform

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

可接受的替代保護措施

如果您並未在伺服器端環境中實行待用資料加密，您或許能採用其他可接受的替代方式來保護平台資料。在此情況下，您應說明下列事項：

1. 平台資料的敏感程度 - 儲存特定平台資料的風險被視為較低或較高。您將必須研究哪些特定平台資料用戶屬性正儲存到伺服器端。
2. 套用以降低特定傷害可能性的控制項
1. 用以避免危害含有平台資料之網路的控制項
2. 用以避免危害可存取平台資料之應用程式／系統的控制項
3. 用以避免遺失含有平台資料之實體儲存媒體（例如已解除委任的網路儲存裝置）的控制項
4. 用以避免遺失含有平台資料之實體儲存媒體（例如已解除委任的網路儲存裝置）的控制項
5. 用以避免未授權存取含有平台資料備份之儲存內容備份副本的控制項
3. 證據的強度 - 務必注意這些保護措施是否已經過獨立稽核員評估，例如作為 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）中）的平台資料進行傳輸期間加密。

下方表格整理了適用於不同傳輸類型的傳輸期間加密政策。

證據指南

如果系統要求您提交此保護措施的證據，請按照準備證據中的指示操作，準備政策／程序和實作證據。若要生成可展示其中一項網路接聽程式之配置的實作證據，可直接使用 Qualys SSL 伺服器測試工具。

• 針對一或多項相同配置的網路接聽程式（包括在任何非標準連接埠中運作的網路接聽程式）執行 Qualys SSL 伺服器測試工具。
• 勾選「不要在板上顯示結果」選項，以避免將結果加入 Qualys 網站。將整個測試結果頁面列印為 PDF，針對任何您向其／由其傳輸平台資料並擁有不同 TLS 配置的網路接聽程式重複上述步驟

實作證據範例

此為 Qualys SSL 伺服器測試工具的匯出範例。請注意配置部分的紅色註解，該註解摘要說明支援的 SSL／TLS 版本。注意：此範例僅保護前兩頁，但您應提供完整的測試匯出。

可接受的替代保護措施

您得使用 TLS 以外不同類型的加密來保護傳輸中的平台資料；若該方式能提供同等保護，則可能為系統所接受。在這種情況下，您應提交所使用之加密的詳情，以供 Meta 審查下列項目：

• 是對稱或不對稱加密？
• 何種加密演算法（例如 AES、BitLocker、TDES、RSA）？
• 最短密鑰長度為何？

測試應用程式和系統的漏洞及安全問題

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

意願

開發人員必須對漏洞和安全問題進行測試，以便主動發現這些問題，最好是在安全事件發生之前就予以預防。

• 使用 Meta 平台透過自己設定和操作之應用程式／系統所編寫的軟體處理平台資料的應用程式開發人員
• 本軟體和系統設定可能包含有心人士會利用的安全性漏洞，導致對平台資料進行未授權的存取。

條件摘要

適用於所有開發人員：

• 為找出安全漏洞，您必須採用下列其中一種方式來測試用於處理平台資料的軟體：

  • 應用程式／系統的滲透測試，或
  • 軟體的漏洞掃描／靜態分析
• 測試的結果必須顯示沒有未解決的極度或高度嚴重漏洞
• 測試必須是在過去 12 個月內完成

針對在伺服器端處理平台資料之開發人員的其他規定：

• 您必須採用以下其中一種方式，特別測試伺服器端軟體是否有安全漏洞：

  • 應用程式／系統的滲透測試，或
  • 漏洞掃描／靜態分析 如果您正使用雲端代管服務供應商，您也必須測試雲端設定以找出安全問題 無論代管方法為何（例如 BaaS、PaaS、IaaS、自我代管或混合式代管），皆適用此規定

證據指南

如果系統要求您提交此保護措施的證據，請按照準備證據中的指示操作，準備政策／程序和實作證據。

如果組織在雲端或伺服器環境中處理平台資料：

• 提交已完成滲透測試或執行 SAST 工具的證據。證據應包含：

  • 測試範圍說明
  • 測試完成日期（應在過去 12 個月內）
  • 在測試期間發現之漏洞的摘要或清單。該摘要或清單必須包含嚴重程度分類（例如極度、高度、中度、低度、資訊性）。通常我們期望沒有未解決的極度或高度嚴重漏洞

• 如果適用（亦即，如果您正使用 AWS、GCP、Azure 或類似雲端代管服務），請提交已進行雲端設定檢查的證據，例如執行 NCC Scout Suite、AWS Config 或類似工具所得的結果。如果這不適用於組織，請在提交的證據中附上文件，說明為何雲端設定檢查不適用。
• 在提交之前，請移除或修訂證據中的敏感資訊，例如詳細的漏洞重現步驟

如果組織並未在雲端或伺服器環境中處理平台資料：

• 提交已完成滲透測試或執行 SAST 工具的證據。證據應包含：

  • 測試範圍說明
  • 測試完成日期（應在過去 12 個月內）
  • 在測試期間發現之漏洞的摘要或清單。該摘要或清單必須包含嚴重程度分類（例如極度、高度、中度、低度、資訊性）。通常我們期望沒有未解決的極度或高度嚴重漏洞。
• 在提交之前，請移除或修訂證據中的敏感資訊，例如詳細的漏洞重現步驟

證據範例

滲透測試 - 某個組織委託測試公司針對自家在伺服器端執行的軟體進行滲透測試，該軟體與 Meta API 整合，並用於處理平台資料。測試公司完成測試並產出如下所示的摘要信函。請注意紅色註釋部分，其醒目標示出測試進行日期所表示的意思（必須在過去 12 個月內），以及一份摘要，列出在測試（或重新測試，如適用）或結論中所發現的極度／高度嚴重的未解決漏洞。在提交之前，請修訂報告中的敏感資訊（特別是任何詳細的漏洞重現步驟）。

靜態分析 - 如果使用不同方法（例如 SAST 工具），請將結果匯出成包含 SAST 進行日期和發現結果（包括各項發現結果的類型及其嚴重程度）清單的文件。

雲端設定檢查

開發人員使用 NCC Scout Suite 檢查他們的雲端設定是否有漏洞和安全問題，而 NCC Scout Suite 為其雲端供應商（在此範例中為 AWS）使用預設規則集。該工具會匯出包含詳細結果的 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 存取權杖和應用程式密鑰？

1. 永遠不要將 Meta API 存取權杖儲存在其他應用程式和用戶（非目前應用程式和用戶）可存取的用戶端裝置上。
2. 如果是儲存在雲端、伺服器或資料中心環境中，請使用資料保存庫（例如 Hashicorp Vault）搭配個別金鑰管理服務（KMS）。

意願

當 Meta API 決定允許哪些動作時，應用程式密鑰和存取權杖是確保安全的基本要件。若未授權的一方獲得存取這些憑證的權限，就能呼叫 Meta 的 API（假冒真正的開發人員），並採取任何我們授權該應用程式的行動（例如讀取 Meta API 中有關某個應用程式用戶的資料）。

• 作為 Meta 平台使用行為的一環，您可以存取敏感憑證。具體項目如下：

  • 存取權杖 - 當用戶授權一個應用程式時，軟體會獲得一個稱為存取權杖的憑證，該憑證會用於隨後的 API 呼叫
  • 應用程式密鑰 - Meta 會與開發人員分享應用程式密鑰，並期望只有組織中受信任的各方（例如應用程式管理員）擁有存取此密鑰的權限
• 能夠讀取這些敏感憑證的未授權方可將其用於呼叫 Meta API，就如同他們是您一般（此行為有時稱為權杖假冒），導致對平台資料進行未授權的存取
• 因此，這些憑證必須獲得保護，以防止未授權的存取，避免假冒行為

條件摘要

存取權杖

1. 在用戶端裝置上 - Meta 存取權杖不得編寫為可由其他用戶或程序讀取。
2. 伺服器端 - 如果您在伺服器端處理或儲存 Meta 存取權杖，則該些存取權杖：
1. 必須使用資料保存庫（例如 Hashicorp Vault）搭配個別金鑰管理服務（KMS）作為保護，並且只有該應用程式能取得解密金鑰
2. 不得寫入記錄檔

應用程式密鑰 - 必須落實以下兩項作法中的其中一項：

1. 您從未在安全的伺服器環境以外之處暴露應用程式密鑰（例如，該項目從未遭網路呼叫退回至瀏覽器或行動應用程式，且密鑰並未嵌入分發至行動或原生／桌上型電腦用戶的代碼）
2. 或者，您必須將其應用程式設定為原生／桌上型電腦類型，這樣 Meta API 將不再信任保護應用程式密鑰的 API 呼叫

證據指南

如果系統要求您提交此保護措施的證據，請按照準備證據中的指示操作，準備政策／程序和實作證據。

包含說明文件，說明當應用程式在伺服器端處理 Meta 存取權限時，為保護 Meta API 存取權杖和應用程式密鑰而採取的政策；並包含能證明您採取之保護措施的證據（例如使用保存庫、呈現以加密格式儲存的數值、要求應用程式密鑰證明的應用程式設定）。

證據範例

一家組織使用 AWS Secrets Manager 以安全地儲存敏感資料，包括 Meta 應用程式密鑰。

一家組織已設定其 Meta 應用程式，以針對 API 呼叫要求應用程式密鑰證明。

可接受的替代保護措施

1. 如果您並未採用資料保存庫或透過應用程式層級加密來保護儲存在伺服器端的存取權杖，您可能：
1. 使用保存庫或應用程式加密（密鑰只能由應用程式存取）來保護應用程式密鑰
2. 另外，設定應用程式，以針對所有對 Meta 的 API 呼叫要求應用程式密鑰證明
2. 如果上述第 1 種方法不可行（亦即無法要求應用程式密鑰證明，因為這樣會封鎖特定必要的 API 呼叫），則 Meta 會考量您能用於控制未授權使用存取權杖之風險（也就是濫用已儲存之存取權杖的風險）的任何其他控制項。

擁有事件應變計畫，並測試事件應變系統和程序

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

意願

所有公司遲早都會發生安全事件，因此組織必須提前規劃如何控制事件、與利害關係人溝通、從發生的事情中恢復和學到經驗，並安排執行上述事項的人員。

• 若發生安全事件，準備好計畫或教戰手冊（並擁有針對負責事項進行培訓的團隊）將能減少事件的時間長度，最終限制平台資料的暴露程度
• 雖然組織不同，事件應變的複雜程度也不同，但我們需要至少一項基本計畫，其中包括關鍵活動：偵測、做出反應、恢復和審查，以及指定人員的分派角色和責任

條件摘要

開發人員必須擁有：

• 符合 Meta 最低條件的事件應變計畫。
• 本文件必須（至少）包含：（1）角色和義務、（2）偵測（3）根據適用法律義務做出反應（例如向相關監管機關和資料當事人透過主體傳送資料外洩通知）和恢復的步驟，以及（4）事件後審查程序
• 證明該計畫最近（過去 12 個月內）曾進行測試，且所有計畫中提及的人員均確實參與測試的文件證據

證據指南

請按照準備證據中的指示操作，準備政策／程序和實作證據。

• 提交事件應變計畫（一份或多份文件）。其中應包含下列主題：角色和義務、偵測、反應和回覆，以及事件後審查

  • 若您沒有事件應變計畫，網路上可取得許多可能會有幫助的資源，例如，請參閱 Counteractive 的事件應變計畫範本以及參考資料和其他文章
• 提交證明您曾在過去 12 個月內測試過該計畫的證據。本證據可採用不同形式，但應包括：

  • 情況說明（例如為因應勒索軟體攻擊而進行的桌上推演）、
  • 進行測試的日期
  • 每位參與者的角色，以及
  • 如果有任何於計畫的角色和義務部分中指定的人員沒有參與，請說明每位缺席人員的理由
• 請在提交證據前修訂其中的敏感資訊（例如個人姓名和電子郵件地址等 PII）範例證據

事件應變計畫

開發人員已根據此範本建立完善的事件應變計畫。這些圖像僅描述目錄，但下方有完整範本的連結。

請參閱完整的 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 Identity and Access Management（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 平台的開發人員必須擁有系統化的方式來透過下列方法管理修補

  • 找出與其應用程式／系統相關的修補
  • 根據曝光率排定急迫性的優先順序，以及
  • 將施加修補作為一項持續進行的業務活動

條件摘要

對於下列軟體元件，依適用情況而定，您必須擁有定義明確並可重複的方式來找出能解決安全性漏洞的可用修補、根據風險排定優先順序，並將施加修補作為一項持續進行的業務活動：

1. 在雲端或伺服器環境中使用的資料庫、SDK、套件、應用程式容器和作業系統
2. 在用戶端裝置上（例如行動應用程式中）使用的資料庫、SDK、套件
3. 成員用來打造並執行應用程式／系統的作業系統和應用程式，例如在員工的筆記型電腦上執行的作業系統和瀏覽器

Meta 並未要求針對這些活動使用任何特定工具。組織通常會使用不同方式來將不同類型的軟體保持在最新狀態（例如，與應用程式一起封裝的資料庫以及員工筆記型電腦的作業系統更新）。

下方圖表說明各種架構類型可能需要修補的位置。

證據指南

如果系統要求您提交此保護措施的證據，請按照準備證據中的指示操作，準備政策／程序和實作證據。

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

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

• 庫存 - 透過螢幕截圖或文件記錄工具或程序，而該工具或項目最終代表需要修補的範圍內資料庫、套件、SDK、容器、應用程式伺服器和作業系統清單。必須有代表軟體類型（例如雲端應用程式、用戶端應用程式、員工裝置）的庫存。
• 找出可用的軟體修補 - 必須有工具或程序來找出與庫存相關的現有安全修補。
• 排定優先順序 - 必須有能夠用來指派相關修補優先順序的工具程序（例如 Jira Tickets、GitHub Issues、追蹤試算表）

  • 修補
  • 透過螢幕截圖或文件進行記錄，證明在找出相關修補並排定優先順序後，就會將其推廣至各個目的地。
• 請加入有關解決和使用生命週期結束（EOL）軟體時間的政策。

證據範例

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

NPM 稽核

開發人員正使用 NPM 稽核來尋找 Node 應用程式中使用之相依性的漏洞。以下範例圖像顯示出多個需要修補的高嚴重性漏洞。

Trivy

開發人員使用 Trivy 來找出機器圖像中的漏洞。以下範例圖像顯示出包含在此圖像中且需要修補的資料庫高嚴重性漏洞。

Windows Server Update Services（WSUS）

開發人員使用 Windows Server Update Services（WSUS）來管理其大量伺服器和電腦／筆記型電腦。以下範例圖像顯示出 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 透過應用程式主控板提供給開發人員的共用密鑰。持有應用程式密鑰即可授權予軟體，透過圖形 API 採取部分動作，因此開發人員必須留意，未獲授權方無法存取應用程式密鑰。

應用程式入侵 - 如果有心人士能夠透過組織的應用程式設定錯誤或漏洞（例如，網頁應用程式的軟體漏洞），在未經授權的情況下存取組織的內部網路，便稱為「應用程式入侵」。防範應用程式入侵的其中一種方法就是，為應用程式進行滲透測試。另請參閱網路入侵。

應用程式容器 - 一種容器，用以封裝軟體程式碼和相關相依性，以便應用程式在不同類型的伺服器（例如，執行 Linux 或 Windows Server 等不同作業系統的伺服器）上執行。開發人員將建立封裝其應用程式的容器映像。應用程式容器引擎或執行階段會代管（執行）容器映像。

應用程式加密 - 一種保護資料的方式，應用程式軟體本身會進行加密和解密作業。相比之下，當應用程式建立與遠端伺服器的安全連線（例如，使用 HTTPS），且雲端服務供應商提供服務以透明地加密待用資料時，傳輸層安全性（TLS）能順暢地加密傳輸中的資料。

應用程式開發介面（API）- 可讓兩部電腦透過網路彼此對話，舉例來說，行動應用程式從中央天氣預報系統擷取特定地點的本日天氣資訊。

應用程式密鑰證明 - 給對 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

身分識別服務供應商（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 通訊，也可能與其他方通訊（例如，透過 Facebook Android SDK 與圖形 API 通訊）。

多重要素驗證（MFA）- 一種驗證方法，要求提供一種以上的要素，才能存取應用程式或系統。單一要素驗證只依賴密碼來驗證用戶，而 MFA 通常會要求密碼以及下列一或多項要素：透過電子郵件或簡訊傳送的代碼、來自驗證應用程式的代碼、生物識別掃描，或安全金鑰。未獲授權的有心人士會使用不明電子郵件地址和常見密碼，不斷嘗試登入帳號，直到成功為止。而設置 MFA 會增加他們登入的難度，藉此保護帳號不被盜用。

N

原生軟體 - 下載並安裝到筆記型電腦或行動裝置的應用程式稱為「原生軟體」（例如 iOS 版 Facebook 應用程式）。相反地，在瀏覽器上執行的應用程式則稱為「網頁應用程式」（例如，使用 Chrome 瀏覽器開啟 Facebook）。

網路入侵 - 如果有心人士能夠透過組織內部網路的設定錯誤或漏洞，在未經授權的情況下存取組織的內部網路，便稱為「網路入侵」。防範網路入侵的方法就是執行網路掃描，在連結網際網路的網路中找出設定錯誤處和安全漏洞。另請參閱應用程式入侵。

網路掃描 - 使用軟體進行下列事項的風險管理程序：（1）識別網路中會回覆遠端通訊的動態伺服器，然後（2）看看這些伺服器中的任一者是否正在執行確知容易受到一或多個安全性入侵影響的舊版本軟體。舉例來說，組織可以定期使用網路掃描，以確保自己的網路周邊沒有預期之外的開啟通訊埠。

節點封裝管理員（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 等先前的通訊協定。也稱為安全資料傳輸層。

安全資料傳輸層（SSL）- 一種過時且不安全的傳輸中資料加密版本。現代採用的安全版本稱為「傳輸層安全性（TLS）」。

伺服器 - 透過網路遠端提供服務的電腦。透過網際網路連結伺服器的瀏覽器和行動應用程式。

無伺服器運算 - 一種雲端運算方式，雲端主機負責管理實體基礎架構、伺服器作業系統和容器。開發人員只負責自訂程式碼和相關程式庫，以及雲端設定。

伺服器端 - 在網路連線另一端（也就是在伺服器上）的資料或運算被稱為「伺服器端」。相反地，在筆記型電腦或行動裝置等本機裝置上的資料或運算被稱為「用戶端」。

單一登入（SSO）- 一種配置方式，應用程式依賴集中的用戶目錄（亦即 IdP）以驗證用戶。除了為組織集中管理用戶帳號和應用程式存取權管理，單一認證組也對用戶有好處，無須再要求用戶為各個應用程式維護不同認證（例如用戶名稱和密碼）。

軟體開發套件（SDK）- 一種程式碼建置組塊，開發人員可用於簡化針對特定需求的開發流程。舉例來說，Meta 為 iOS 和 Android 開發人員建立藉由圖形 API 簡化工作流程的 SDK，並加以維護。與程式庫類似，在自家應用程式使用 SDK 的開發人員必須時時確保 SDK 是最新狀態。

軟體即服務（SaaS）- 可讓顧客透過網際網路使用雲端型應用程式。與 PaaS 或 IaaS 不同，SaaS 應用程式的顧客不用部署自訂程式碼，也無須負責設定、升級或修補 SaaS 應用程式，因為這全部都由 SaaS 軟體廠商負責處理。舉例來說，一些熱門的 SaaS 產品包括：Dopbox、MailChip、Salesforce、Slack。

靜態分析 - 查看靜態應用程式安全測試

靜態應用程式安全測試（SAST）- 針對原始程式碼執行特殊工具，以找出軟體中漏洞的一種方法。SAST 工具會找出潛在漏洞，例如列於 OWASP 前 10 名專案內的漏洞，接著開發人員負責檢查發現結果，從誤判為真的結果中找出實際為真的結果，並且修正軟體中的漏洞。SAST 很有幫助，因為開發人員將軟體部署到生產階段前，可以透過 SAST 找出漏洞。不過，與滲透測試不同，SAST 工具無法找出與應用程式生產設定相關的漏洞。

T

透明資料加密 - 一種待用資料加密方式，通常使用在資料庫儲存體上（亦即資料庫內容本身及其紀錄檔）。在此配置中，資料庫軟體管理加密金鑰，並透明地處理加密作業（在寫入時）和解密作業（在讀取時）。

傳輸層安全性（TLS）- 一種傳輸中資料加密配置，使用加密來保護透過網路傳送的資料，以免在網路路徑上受到竊聽者攻擊。SSL 是過時的舊技術，而 TLS 是現代採用的安全版本。

雙重驗證（2Fac）- 多重要素驗證的同義詞。保存庫 - 一種密鑰管理系統，用於管理加密金鑰、存取權杖和其他認證等敏感資料。保存庫可嚴謹地控制哪些人能夠存取保存庫中的密鑰，並提供如稽核紀錄等額外服務。

V

虛擬機器（VM）- 與應用程式容器非常相似。VM 在稱為「Hypervisor」的主機上執行，應用程式容器則在容器引擎中執行。主要的差異在於，VM 映像包含作業系統，應用程式容器則否。VM 及應用程式容器都包含應用程式和相依性（如程式庫）。

虛擬私有雲端（VPC）- 這是 AWS 用來指稱一組雲端資源的詞語，這組雲端資源類似於雲端技術出現前之資料中心內的傳統網路。

漏洞 - 系統或應用程式中可能遭到惡意探索（例如，讀取有心人士本來無權讀取的資料）的瑕疵

漏洞揭露計畫（VDP）- 組織用於向研究人員（有時稱為道德駭客）請求安全漏洞報告的一種方法，組織可以透過這份報告找出並修正漏洞，以免有心人士惡意探索漏洞。有效的 VDP 需要一組研究人員、組織內的分析師和工程師參與，研究人員負責主動尋找漏洞，分析師負責檢視和分級收到的揭露內容，工程師熟悉網路安全相關知識，因此能夠針對漏洞建立並部署修正程式。

漏洞掃描 - 一種使用軟體搜尋伺服器、網路和應用程式中漏洞的方法。與滲透測試相比，漏洞掃描執行成本較低，因此可以重複執行（例如每月或每季），不過滲透測試往往能找到漏洞掃描遺漏的漏洞，因為技術純熟的滲透測試人員擁有分析技能和直覺，純自動化的掃描方法很難比得上。另請參閱網路入侵掃描。

W

網頁應用程式 - 網頁應用程式是在瀏覽器內執行的程式，並且包含各種資源，例如 HTML 文件、JavaScript 程式碼、影片和其他媒體，以及 CSS 樣式。行動應用程式與網頁應用程式不同，若要使用前者，用戶必須從應用程式商店將行動應用程式安裝到手機上；若要使用後者，用戶只要使用瀏覽器就能從遠端伺服器擷取網頁應用程式（例如 www.facebook.com），無須安裝。