這份文件已更新。
中文(香港) 的翻譯尚未完成。
中文(香港) 的翻譯尚未完成。
英文更新時間：
數據保護評估常見問題
什麼是資料保護評估
什麼是資料保護評估？
- 存取某幾類資料的應用程式每年都必須完成資料保護評估。評估中的問題專門用於判斷開發人員在使用、分享和保護平台資料方面，是否遵守我們的《平台使用條款》。
什麼是平台資料？
- 「平台資料」是指您透過本平台或經自己的應用程式，而直接或間接從我們獲得的任何資訊、資料或其他內容，而且無論是在您同意本《使用條款》之前、當天或之後都適用，範圍涵蓋匿名資料、彙總資料或從此類資料衍生出來的資料。平台資料包含應用程式憑證、專頁憑證、存取憑證、應用程式密鑰和用戶憑證。
- 您透過應用程式從 Meta 收到的所有資料，也都視作平台資料。舉例來說，用戶編號、用戶電郵地址和用戶朋友都屬於平台資料。
這項評估與應用程式審查和數據使用情形檢查有何差別？
如何為資料保護評估做好準備？
為什麼必須完成資料保護評估
為什麼必須完成資料保護評估？
- 有見私隱監管環境不斷轉變，用戶私隱權所受的威脅也在一直變化，因此我們各方都有責任，努力讓使用我們產品和服務的用戶對我們抱有信心，而第一步就是要確保用戶對資料在互聯網上的使用、分享和保護方式感到可信任。
- 如果應用程式會在我們的平台上存取某幾類資料，這些應用程式的開發人員就必須完成資料保護評估。
- 根據過往經驗，已有不少開發人員跟從我們的標準，成功實行新的資料安全措施。如果我們能夠就此攜手合作，就能提高互聯網上的資料安全標準，贏得我們全球數十億名服務用戶的信任。
- 有見私隱監管環境不斷轉變，用戶私隱權所受的威脅也在一直變化，因此我們各方都有責任，努力讓使用我們產品和服務的用戶對我們抱有信心，而第一步就是要確保用戶對資料在互聯網上的使用、分享和保護方式感到可信任。
程序
如何判斷是否需要完成資料保護評估？
如何確保我能順利收到與資料保護評估相關的電郵通訊資料？
如何得知可以開始完成資料保護評估？
如果對資料保護評估所涵蓋的主題有疑問，可以提出嗎？
我收到了 DPA 審查團隊的訊息，其中包含一個幫助頁面的連結，但我無權存取。我可如何存取此頁面？
提交
需要在多久後提交資料保護評估？
- 由您收到第一則通知起，您必須在 60 個曆日內完成資料保護評估。
資料保護評估必須多久提交一次？
- 此為每年一次的要求。
問卷太長了，可以儲存進度並分次完成嗎？
- 可以。這個表格會自動儲存，方便您日後續填。
如何查看提交狀態？
- 評估的各種情況所代表的意義如下：
- 尚未開始：開發人員收到通知要求他們在期限內完成資料保護評估，但他們尚未開始填寫表格。
- 期限已過：已超過提交資料保護評估的期限。開發人員必須完成評估，否則應用程式就會受到限制。
- 已提交，但需要提供更多資訊：開發人員已提交填寫完畢的資料保護評估，Meta 也已開始審查，但有需要釐清的部分。
- 已提交，且發現違規問題：開發人員已提交填寫完畢的資料保護評估，Meta 也已開始審查，結果發現應用程式違反了一項或多項《平台使用條款》。視乎違規行為的嚴重性而定，應用程式或有機會在受到限制前解決問題。然而，我們不為嚴重違規內容提供警告期。
- 已提交，正在審查中：開發人員已提交填寫完畢的資料保護評估，或已應要求提供更多資訊。Meta 也已開始審查，但未完成評估。
- 已提交，且未發現違規問題：開發人員已提交填寫完畢的資料保護評估，Meta 也已完成審查，結果發現應用程式確實遵守《平台使用條款》，無須採取進一步的行動。
- 評估的各種情況所代表的意義如下：
如何下載去年填寫過的答案？
- 很抱歉，您無法下載上次填寫過的評估，因為我們為了讓問題更清楚，已經修改過問卷內容。這次提交填寫過的評估後，您將可查看並下載其 PDF 檔案。
審查
Meta 審查人員在作出任何一種判決以前，會與我聯絡並提出其他問題嗎？
- 如果 Meta 審查人員在審查您的作答內容後認為需要更多資訊，我們就會與您聯絡並提出要釐清的問題，而您會收到下列形式的通知：
- 通知：
- 開發人員或商業帳戶聯絡電郵信箱會收到一封電郵。在此編輯您的個人開發人員通知設定。
- 應用程式管理中心的警示收件匣會收到郵件。
- 應用程式管理員會收到透過應用程式管理中心傳送的通知。
- 需採取的行動：
- 狀態：需採取的行動
- 通知：
- 如果 Meta 審查人員在審查您的作答內容後認為需要更多資訊，我們就會與您聯絡並提出要釐清的問題，而您會收到下列形式的通知：
我收到的電郵指 Meta 需要更多資訊，為什麼？
- 您可以趁著這個機會與 Meta 審查人員一起處理問題，他們必須有十足的把握，才能判斷應用程式是否遵守《平台使用條款》。
如何回覆 Meta 審查人員的問題？
- 您收到的通知（如上所述）會附有評估的連結，按下後就能在頁面頂部進一步了解 Meta 審查人員要求提供哪些額外資訊。請在表格中作出回應，並視乎需要上載文件。回應完畢後，請務必點擊「提交」。
需要在多久後回覆 Meta 審查人員的問題？
- 收到「需要提供更多資訊」的要求後，您必須在 5 個工作天內回應。如果沒有在最初 5 天內回應，我們會自動給予兩次延期的機會，共計 15 個工作天。
回應違規問題
應用程式會因為違反《平台使用條款》而受到限制嗎？
- 可以。視乎違規情況而定，應用程式可能會受到不同的限制。
如果發現違規問題，Meta 審查人員會與我聯絡嗎？
- 可以。如果 Meta 審查人員在審查您填寫的評估後發現違規問題，您會收到下列形式的通知：
- 通知：
- 開發人員或商業帳戶聯絡電郵信箱會收到一封電郵。在此編輯您的個人開發人員通知設定。
- 應用程式管理中心的警示收件匣會收到郵件。
- 應用程式管理員會收到透過應用程式管理中心傳送的通知。
- 需採取的行動：
- 狀態：發現違規問題
- 通知：
- 可以。如果 Meta 審查人員在審查您填寫的評估後發現違規問題，您會收到下列形式的通知：
如果沒有回應，會有什麼結果？
- 沒有回應即視為違反《平台使用條款》。
如何要求延長違規問題的回應期？
- 如果每個違規問題的回應期限是 3 天內，就會顯示「要求延期」按鈕。您有兩次要求延期的機會，時間長度皆與警告期（視乎違規問題而定）相同，且會自動獲得批准。
如何解決在資料保護評估中發現的違規問題？
- 如果應用程式已因出現違規問題而受到限制，您可以在回應時提交證據，證明已作出補救措施來解決問題。在您提交回應後，Meta 審查人員就會加以審查，並直接透過「解決違規問題」表格回覆。
平台使用條款 3（資料使用）
我的應用程式或用戶所在的司法管轄區（例如歐盟或加州）沒有適用的法律，規定我必須應用戶要求刪除其資料。根據 Meta 的政策，我的應用程式是否仍須應用戶要求刪除資料？我是否也仍須在私隱政策中附上指示來說明他們可以如何提出刪除要求？
- 是。除非有適用的法律或規範免除您遵守 Meta 以下兩項規定的義務，否則即使您應用程式或用戶所在的司法管轄區沒有規定您必須應用戶要求刪除其資料，您也必須按照《平台使用條款》規定 1) 應用戶要求刪除平台資料，以及 2) 在私隱政策中說明用戶可以如何提出資料刪除要求。
我的公司使用平台資料來讓用戶能在約會交友應用程式中選擇所需的配對條件，或是針對特定內容（例如銷售酒精飲品）設定年齡限制。這是否表示我們使用平台資料的方式是令某些人群因種族、民族、膚色、國籍、宗教、年齡、性別、性取向、性別認同、家庭狀況、殘疾、疾病或遺傳狀況而處於不利處境？
- 不是。為了讓用戶能在約會交友應用程式中設定條件，或是針對內容設定年齡限制而使用平台資料，在資料保護評估中並不算是令某些人群因種族、民族、膚色、國籍、宗教、年齡、性別、性取向、性別認同、家庭狀況、殘疾、疾病或遺傳狀況而處於不利處境。
如果我的應用程式因為不設自動刪除資料的功能而無法在 Meta 所規定的部分或所有情況下刪除平台資料，會有什麼後果？
- 刪除操作不一定要自動執行。在資料保護評估中回答有關您是否會在特定情況下刪除平台資料的問題時，請明確表示您的政策是手動還是自動刪除資料。
根據 Meta 使用條款的規定，我必須在用戶刪除應用程式帳戶時一併刪除他們的平台資料。不過，我的應用程式沒有得知用戶何時刪除 Facebook 帳戶所需的回呼功能，因此無法遵守上述規定。這是否表示我的應用程式違反 Meta 使用條款？
- 不是。這不代表應用程式違反 Meta 使用條款。回呼並非必要功能，但如果您設有這項功能，就必須在用戶刪除 Facebook 帳戶時一併刪除平台資料。此外，您也必須在用戶刪除應用程式內帳戶時，一併刪除平台資料。
平台使用條款 4（私隱政策）
我的應用程式私隱政策內含一項聲明，指出用戶可以要求刪除其資料。這樣是否就已足夠？
- 只有這項聲明並不足夠。您必須附上指示，說明用戶可以如何向您提出要求。
平台使用條款 5（服務供應商和技術供應商）
什麼是服務供應商？
- 服務供應商是指您僱用來為您提供與平台或任何平台資料相關服務的實體。常見的大型服務供應商包括 Google Cloud 和 Amazon Web Services（AWS）。
什麼是子服務供應商？
- 子服務供應商是指另一間服務供應商所採用的服務供應商，目的是為這間服務供應商提供與平台或任何平台資料相關的服務。
什麼是技術供應商？
- 技術供應商是指特定應用程式的開發人員，其中這些應用程式的主要目的是讓用戶存取並使用平台或平台資料。一般而言，技術供應商的主要目的是讓應用程式用戶能存取並使用 Meta for Developers 或平台資料。
怎樣才算是問題 4 所述的「其他」用途的書面協議？
- 書面協議的範例包括服務條款、標準非談判協議或已簽署的合約。
平台使用條款 6（資料安全性）
如何證明我遵守 Meta《平台使用條款》（資料安全性）第 6.a.i 節的規定？
- 為了證明您遵守規定，我們會詢問您是否擁有第三方審計機構所頒發的資訊安全性證書。這張證書並非必備條件，但可作為您遵守規定的其中一種證明。此外，我們也會詢問您採取了哪些特定保護措施。Meta 會依照我們內部的標準評估您的作答內容；一旦有其他問題或需要您設立額外保護措施，就會與您作進一步跟進。
我是否必須向第三方審計機構取得資訊安全架構（ISF）或網絡安全架構（CSF）證書？
- 不是。您無需取得審計機構的證書。機構如果持有 SOC 2、ISO 27001、ISO 27018 或 PCI DSS 證書，可以提交其中任何一種證書，以此作為證明。
- 證書必須與儲存或處理平台資料時所在的運算環境相關。
- 請注意，不論您是否提交了安全性證書，我們都會詢問您採取了哪些特定保護措施。
- 不是。您無需取得審計機構的證書。機構如果持有 SOC 2、ISO 27001、ISO 27018 或 PCI DSS 證書，可以提交其中任何一種證書，以此作為證明。
如果我沒有提交安全性證書，我需要回答哪些有關資料安全保護措施的問題？
- 所有需要完成資料保護評估的開發人員都要回答自己有否採取以下措施：
- 為所有平台資料儲存空間（例如所有資料庫檔案、備份以及物件儲存區）執行待用資料加密
- 技術和／或行政管制措施，以便保護儲存在機構裝置（例如遺失或遭竊的手提電腦或可卸式媒體）上的平台資料。符合規定的管制措施有很多種，包括記載了年度培訓的政策書面文件，或是不應將平台資料儲存在這類裝置上的提醒，甚至是技術管制措施。
- 為傳輸平台資料所用的所有公用網絡連線啟用 TLS 1.2 或更高層級的加密機制
- 除此之外，如果應用程式能夠存取更高風險的資料，其開發人員還需要回答有否採取以下額外的安全保護措施：
- 最少每 12 個月測試一次應用程式和系統，看看是否有漏洞和安全性問題
- 保護憑證和存取憑證等敏感資料
- 測試用於處理資料安全事件（例如資料外洩和網絡攻擊）的系統和程序
- 要求必須完成多重驗證，才能取得遙距存取權
- 設立系統以維護帳戶（分配、撤銷以及審查各種存取權和權限）
- 設立系統以持續更新系統程式碼和環境，包括伺服器、虛擬機器、發佈版本、資料庫、封裝以及防毒軟件
- 備註：上述清單未有列出部分項目，無法用於替代您機構所需設立的相應資訊安全計劃。
我被問及自家機構有否為所有平台資料儲存空間執行待用資料加密，這條問題涉及哪些範圍？我需要同時為雲端儲存空間和用戶端儲存空間執行待用資料加密嗎？
- 啟用待用資料加密功能後，平台資料就必須使用專屬解密密鑰才能破解，可確保安全。這樣防護效果就會更上一層樓，使他人無法未經授權讀取資料。
- 在與所有應用程式用戶相關的平台資料趨於集中化的伺服器或雲端環境中，待用資料加密功能可以降低資料外洩的風險。舉例來說，這項功能可以防堵未經授權存取資料庫備份檔案等威脅，因為備份檔案所受到的保護並不如實際資料庫本身嚴密。
- 如果您的機構將平台資料儲存在雲端，就必須使用待用資料加密功能或適合的補償性控管措施來保護這些資料。不論您是在應用程式級別（例如軟件會加密／解密資料庫的特定欄位），還是針對整個磁碟進行加密都可以。雖然我們建議採用符合業界標準的加密功能（例如 AES、BitLocker、Blowfish、TDES、RSA），但沒有要求一定要使用任何特定的演算法或密鑰長度。
- 如果您的機構不是將平台資料儲存在雲端，這項規定就不適用。
- 為了避免產生疑義，您服務的個別用戶持續存放在網絡或流動用戶端的資料，並不在這個問題涵蓋的範疇內。
- 如果您的機構是透過雲端 IaaS 產品（例如 AWS EC2、Microsoft Azure IaaS 和 Google Compute Engine）儲存平台資料，或是您使用自我代管服務，甚至是兩者混合使用，這個問題就不適用。
- 不過，還有一些後端代管模型屬於特殊情況：使用 SaaS 產品 - 如果您的機構是透過 SaaS 產品（例如 MailChimp 或 Salesforce）儲存平台資料，這個問題就不適用。建議您改為前往數據保護評估的「服務供應商」部分說明這個關係。使用 PaaS 代管服務 - 如果您的機構是透過 PaaS 產品（例如 AWS Elastic Beanstalk、Google App Engine、Force.com）儲存平台資料，這個問題就不適用。建議您改為前往數據保護評估的「服務供應商」部分說明這個關係。使用 BaaS 代管服務 - 如果您的機構是透過 BaaS 產品（例如 AWS Amplify、Azure Mobile Apps、Azure Playfab、Google Firebase 和 MongoDB Switch）儲存平台資料，這個問題就不適用。建議您改為前往資料保護評估的「服務供應商」部分說明這個關係。
我被問及如何防止平台資料儲存在機構和個人裝置上。哪些是符合規定的防範措施？
- 開發人員必須設立技術和／或行政管制措施（例如政策和規則），以便保護機構裝置（例如遺失或遭竊的手提電腦或可卸式媒體）上儲存的平台資料。符合規定的管制措施有很多種，包括記載了年度培訓的政策書面文件，或是不應將平台資料儲存在這類裝置上的提醒，甚至是技術管制措施。
我被問及自家機構是否為傳輸平台資料所用的所有網絡連線啟用 TLS 1.2 或更高層級的傳輸協定。這條問題涉及哪些範圍？
- 這條問題涉及透過互聯網傳輸的任何資料，其中包括從網絡或流動用戶端傳輸到您雲端環境的平台資料，以及在周遊互聯網的各個雲端環境之間的傳輸操作。
- 凡是可以觀察到網絡流量的人，都能存取透過互聯網傳輸的平台資料。因此，這些資料必須使用加密功能保護，以防未經授權方讀取。如果平台資料是透過不受信任的網絡（例如互聯網）傳輸，傳輸中加密功能會使這些資料只能在來源和目標裝置上識別，從而達到保護的效果。換言之，傳輸過程的中途方無法讀取平台資料，即使他們能看到網絡流量（又稱中間人攻擊）也是一樣。TLS 技術可供瀏覽器用於確保與銀行等網站的通訊安全無虞，因此是傳輸中加密的其中一種常見形式。
- 下圖說明了可能涉及平台資料傳輸的網絡連線。黃色虛線代表您有責任使用 TLS 加密功能確保安全的連線。如果資料完全在 AWS 或 GCP 虛擬私有雲端（VPC）等私有網絡內傳輸，建議使用 TLS（但非必要）。
下表總結了傳輸 Meta 平台資料的 TLS 加密要求。
請諮詢您機構的資訊安全總監（CISO）或同等角色，或者向合資格的網絡安全公司查詢，由他們指引您如何為自家應用程式採取相應的加密和其他補償性控制措施。連接 TLS 政策 終端用戶裝置（手機、個人電腦、平板電腦等）和您的伺服器或雲端架構之間的通訊
必須為相容裝置啟用 TLS 1.2 或更高層級的協定
可啟用 TLS 1.0 和 1.1，以便與舊款裝置相容
您的伺服器或雲端架構與任何遙距伺服器、雲端架構或第 4 方服務之間的通訊
必須執行 TLS 1.2 或更高層級的協定
完全位於私有資料中心、伺服器或雲端架構中的組件通訊
建議使用 TLS 加密，但對於完全在私有雲端網絡中傳輸的平台資料，這並非硬性規定
Facebook 與任何裝置、伺服器或雲端架構之間的通訊
不在資料保護評估的範圍內；這類傳輸操作的 TLS 政策由 Facebook 控管
我被問及自家機構是否最少每 12 個月測試一次應用程式和系統的漏洞和安全問題，哪些是符合規定的測試類型？
- 存取 Meta 平台的應用程式開發人員會撰寫軟件，以便存取及處理平台資料，並為軟件用戶提供服務。這個軟件（和相關系統配置）可能包含有心人士可利用的安全漏洞，導致平台資料遭到未經授權存取。因此，開發人員必須進行測試，看看是否有可主動找出的漏洞和安全問題，在理想狀態下防範安全性事件於未然。
- 安全性測試應在整個應用程式生命週期內以多種形式進行。一般而言，您應結合採用多種測試方法，包括普通的漏洞掃描、應用程式安全掃描以及滲透測試等；而在處理個人資訊等敏感資料的區域，您更應使用多種測試方法。
- 您必須已測試處理平台資料所用的軟件來找出安全漏洞，方法是對軟件進行滲透測試，或是進行漏洞掃描／靜態分析。測試結果必須顯示沒有任何未解決的重大或高嚴重性漏洞。測試必須是在過去 12 個月內完成。
- 此外，如果您的機構是在雲端處理平台資料，則必須已進行符合規定的安全漏洞測試，以在您的雲端軟件中找出安全漏洞，方法是對他們的應用程式／系統進行滲透測試，或是進行漏洞掃描／靜態分析。此外，您也必須已測試雲端設定是否有安全性問題。不論代管做法為何（例如 BaaS、PaaS、IaaS、自我代管或混合使用），這項規定都適用。
我被問及自家機構有否採取措施以保護憑證和存取憑證等敏感資料，這條問題涉及哪些範圍？
- 應用程式密鑰和存取憑證為可透過 Meta API 取得的資料提供了存取權控管機制，因此是這類 API 安全性的基礎。如果未經授權方取得了這些憑證的存取權，他們可能會呼叫 Meta API（冒充真正的開發人員），並進行我們授權應用程式執行的任何動作（例如讀取 API 中的應用程式用戶資料）。
- 開發人員可在使用 Meta 平台時存取敏感憑證，當中指的具體是：
- 應用程式密鑰：Meta 會將應用程式密鑰分享給開發人員，但我們預計開發人員機構內只有受信任方（例如應用程式管理員）可存取這個密鑰
- 存取憑證：用戶授權應用程式時，開發人員會取得某項憑證，也就是後續發出 API 呼叫時所用的存取憑證
- 如果未經授權方可讀取這類敏感憑證，就能冒充開發人員的身分使用這類憑證呼叫 Meta API（這有時稱為憑證假冒），導致平台資料遭到未經授權存取。因此，這類憑證必須受到保護，免遭未經授權存取，以防假冒問題發生。
- 應用程式密鑰：以下兩種情況必須有一種成立：
- 開發人員從未經應用程式密鑰洩漏到安全伺服器環境外部（例如從未由網絡呼叫傳回到瀏覽器或流動應用程式，且密鑰未嵌入到發佈至流動或原生／桌面用戶端的程式碼）
- 開發人員必定已將應用程式設為「原生／桌面」類型，讓我們的 API 不再信任內含應用程式密鑰的 API 呼叫
- 存取憑證：以下所有情況都必須成立：
- 在用戶端裝置上：Meta 存取憑證不得寫入，使得其他用戶或程序可以讀取該憑證
- 在雲端中：如果開發人員是在雲端中處理或儲存 Meta 存取憑證，這些存取憑證：
- 必須受到保存庫保護或使用應用程式加密功能保護，此時解密密鑰只有應用程式才能存取，且不得寫入到記錄檔案中
- 或者，必須受到適合的補償性管制措施保護
我被問及機構是否至少每 12 個月測試一次安全事件回應系統和程序。這條問題涉及哪些範圍？
- 安全性事件可以隨時在任何公司內發生，因此機構必須預先做好規劃，決定各項工作的負責人，以便妥善控制這類事件、與相關利益相關者溝通、進行復原工作，並從這些經歷中吸取教訓。一旦發生安全性事件，如有事先與受過相關訓練的人員團隊一起做好規劃或擬定策略，就可以縮短該事件的持續時間，進而降低平台資料洩漏的程度。
- 雖然事件回應的縝密度會因機構而異，但我們要求最少必須制定一項包含密鑰活動的基本計劃來進行偵測、回應、復原和審查工作，並為具名人員指派職務和責任。此外，您也必須已經記載該項計劃最近（過去 12 個月內）經過測試，且計劃中列名的所有人員皆有參與的證據。
我被問及自家機構有否要求必須完成多重驗證，才能取得遙距存取權。這條問題涉及哪些範圍？
- 廣告客戶取得機密資料存取權時常用的技巧，是先取得開發人員在建立或運作應用程式／系統時所用工具的存取權。某些設計精密的工具可用於取得用戶憑證（例如網絡釣魚攻擊），以便駭入只有密碼保護的帳戶；多重驗證可以提高安全性，有助於避開這項風險。
- 軟件開發人員會使用各式各樣的工具，來建立、部署和管理他們的應用程式／系統。這些工具經常會透過互聯網遙距使用（例如員工在家上班並推出新的軟件功能，或是更新雲端設定）。使用單一驗證機制（用戶名稱和密碼）保護的工具，很有可能會遭受帳戶接管攻擊。舉例來說，攻擊者可能會使用多項工具，嘗試以其中一項工具所洩漏出的用戶名稱和密碼組合存取另一項工具。多重驗證則會在用戶登入時要求輸入密碼以外的另一項資訊（例如驗證應用程式所產生的代碼），以防遭受上述攻擊。
- 機構在處理平台資料時，必須以多重驗證（亦即不只使用密碼）來保護這些工具的遙距存取權：
- 用於部署和管理應用程式／系統程式碼或配置變更的工具
- 雲端或伺服器環境的管理員存取權（如適用）
- 當中指的具體是：
- 協作／通訊工具：例如企業電郵信箱或 Slack
- 程式碼存放庫：例如 GitHub，或是其他用於追蹤應用程式／系統程式碼或配置變更的工具
- 如果機構是在雲端／伺服器環境中處理平台資料：
- 軟件部署工具：用於將程式碼部署到雲端／伺服器環境中的工具，例如 Jenkins 或其他連續整合／連續部署（CI/CD）工具
- 管理工具：入口網站或其他存取權，用於管理／監察雲端或伺服器環境
- 伺服器遙距存取權：SSH、遙距桌面或類似工具，用於遙距登入在雲端或伺服器環境中運作的伺服器
我被問及自家機構有否設立系統以維護帳戶（分配、撤銷以及審查各種存取權和權限），這條問題涉及哪些範圍？
- 要避免他人未經授權使用帳戶來取得平台資料的存取權，就必須養成良好的帳戶管理習慣。特別是，如有不再需要使用的資源或系統，開發人員必須撤銷相關存取權。帳戶是基本管理單位，可讓用戶存取系統、資料和管理員功能。帳戶會取得執行特定動作的權限；建議您只授予帳戶所需的最低權限，也就是所謂的最低權限原則。
- 如果有人從機構離職，他們的用戶帳戶就必須立即被停用，原因如下：
- 防止此人（即前員工）存取資料，以及
- 降低未經授權者在無人發現的情況下使用帳戶的可能性。舉例來說，有心人士可能會利用社交工程技術，令 IT 服務台重設帳戶密碼。如果該帳戶為現任員工所有，該員工可能會回報自己無法登入的問題，而如果帳戶仍然有效但為離職員工所有，這個問題就不太可能會被注意到。
- 有鑑於此，機構必須透過系統化的方式管理帳戶、授予權限，以及撤銷不再需要的存取權
- 開發人員必須擁有為上述個別工具／系統／應用程式管理帳戶的工具或程序：
- 用於與彼此通訊的工具／系統／應用程式，例如 Slack 或企業電郵信箱
- 用於推出軟件的工具／系統／應用程式，例如程式碼存放區，以及
- 管理並運作系統（適用於處理平台資料）
- 開發人員必須定期審查（例如每 12 個月不少於一次）存取權授予情形，並建立在以下時機撤銷存取權的程序：(1) 不再需要該存取權，以及 (2) 不再使用該存取權
- 此外，他們也必須建立程序，以便在有人離開機構時立即撤銷對這些工具的存取權
我被問及自家機構有否設立系統以持續更新系統程式碼和環境，包括伺服器、虛擬機器、發佈版本以及防毒軟件，這條問題涉及哪些範圍？
- 軟件元件會定期更新或修補來解決安全漏洞，最終在不再受支援時壽終正寢。封裝或採用這些元件的開發人員必須隨時掌握最新狀況，以免執行的軟件出現已知漏洞。
- 應用程式開發人員會採用多種第三方軟件，來執行用於處理平台資料的應用程式／系統。舉例來說，開發人員會採用以下部分或所有：
- 程式庫、SDK、套件：開發人員會使用自己的自訂程式碼封裝這些項目來建立應用程式
- 虛擬機器映像、應用程式容器和作業系統：應用程式會在一個或多個這類容器中執行，而這些容器則會提供虛擬化以及網絡和儲存空間存取權等服務
- 瀏覽器、作業系統，以及其他由開發人員的員工／協作者使用的應用程式：在流動裝置和手提電腦上執行，且由開發人員用於建立並執行系統的軟件
- 安全漏洞經常出現在這些元件中，修補檔案也就因此推出。修補檔案所修正的漏洞屆時會在公開資料庫中披露，並附上嚴重性評分（低、中、高或重大）。因此，我們平台上的開發人員必須透過系統化的方式管理修補檔案，例如：
- 找出與其應用程式／系統相關的修補檔案
- 根據曝光程度優先處理緊急項目，以及
- 將修補檔案視為持續進行的業務活動來套用
- 對於下列軟件元件，開發人員必須視乎情況透過系統化的方式，找出可用修補檔案來解決安全漏洞，並根據風險等級決定優先順序，同時將修補檔案視為持續活動來套用：
- 用於雲端或伺服器環境的程式庫、SDK、套件、應用程式容器和作業系統
- 用於用戶端裝置（例如流動應用程式內）的程式庫、SDK 和套件
- 機構成員用於建立並運作其應用程式／系統的作業系統和應用程式，例如在員工手提電腦上執行的作業系統和瀏覽器
如果我沒有採取其中一項或多項所需的安全控制措施，但是實施了其他安全控制措施以作彌補，這種情況下我應該怎樣做？
我被問及有否提供公開的渠道，以便用戶向我們回報安全漏洞問題。我們是否必須就此設立專屬渠道？
我在 DPA 審查團隊傳送的訊息中看到他們使用問題編號作為參照。這些編號是指什麼？
- 您可能會在審查團隊傳送的訊息中看到使用問題編號作為參照的情況。這些編號主要用於內部審查程序；以下提供相關資訊供您參考：
我收到了 DPA 審查團隊有關欠缺政策或程序證明或相關資料不足的意見。政策或程序證明是什麼？
- 您可能會收到跟進問題，要求提供與一個或多個資料安全問題（Meta 審查團隊可能會以下列其中一個編號表示具體問題：Q9、Q10、Q11、Q12、Q13、Q14、Q15、Q16 和 Q17）相關的政策或程序證明。
在所有這些情況下，政策或程序證明均指書面的文件，當中說明您的機構實施特定資料安全保護措施的方法。例如，您的機構可能需要提供以下書面資料： - 驗證政策文件，當中說明可用於存取平台資料的所有業務、開發和系統管理工具都必須受多重驗證機制保護。
- 加密政策，當中說明所有 Meta 平台資料都必須受傳輸中加密和待用資料加密方式保護。
- 修補程序，當中列出必須多久執行一次相關步驟來識別任何影響機構雲端應用程式的可用安全修補程式、如何對各個安全修補程式進行影響評估、根據嚴重性確立部署修補程式的時間上限，以及如何部署修補程式。
我收到了 DPA 審查團隊有關欠缺執行證明或相關資料不足的意見。執行證明是什麼？
- 您可能會收到跟進問題，要求提供與一個或多個資料安全問題相關的執行證明。資料安全問題有時會以下列編號表示：Q9、Q10、Q11、Q12、Q13、Q14、Q15、Q16 和 Q17。
在所有這些情況下，加入執行證明對您證明書面政策或程序的執行情況至關重要。這類證明包括管理系統和工具輸出的螢幕截圖，當中應展示機構實際上如何實行其保護措施。可接受的執行證明必須能夠證明您機構的執行方法符合 Meta 對保護措施的要求。您必須針對每項保護措施提交至少一份執行證明。
詳情請參閱我們的開發人員文件，了解如何為每項保護措施準備證明：
我被問及如何保護機構和個人裝置上的平台資料。Meta 的要求是什麼？
- 您可能會收到跟進問題，詢問您的機構如何防止機構和個人裝置上儲存的平台資料遺失。這些問題亦可能會以編號 Q10a 或 Q10b 表示。
Meta 要求您證明以下至少一項： - 您的機構採取措施封鎖存取含有 Meta 平台資料的系統之行為，但符合以下一種或兩種情況的裝置除外：
- 所有裝置必須啟用全磁碟加密功能，例如透過 FileVault 或 BitLocker。
- 所有裝置必須運行端點 DLP 軟件，例如 Microsoft Intune 或 Symantec DLP。
- 您的機構制定了禁止任何機構成員在任何機構或個人裝置上儲存 Meta 平台資料的政策，並且您有書面證明來證明機構成員有義務遵守此政策。
- 您機構制定的政策有以下規定：
- 只限需要存取權且有授權商業目的之個人可處理機構裝置上的平台資料；以及
- 達成該授權商業目的後，這些人士必須從這類裝置上刪除平台資料。
- 根據軟件構建方式，任何機構成員均絕對無法存取 Meta 平台資料；例如，根據軟件的構建，Meta 平台資料僅儲存在終端顧客裝置的暫用記憶體中
Facebook 或 Meta 應用程式密鑰是什麼？
- 您可能會收到跟進問題，詢問您如何保護 Facebook 或 Meta 應用程式密鑰。這個問題亦可能會以編號 Q13 表示。
應用程式密鑰是一個與 Facebook 應用程式關聯的參數，可在某些 API 呼叫中用作存取憑證，以變更應用程式配置，例如配置 Webhook 回呼。您可以在「設定」>「基本」下的開發人員管理中心找到您應用程式的 Facebook 密鑰。如需進一步了解應用程式密鑰，請參閱我們有關登入安全的開發人員文件。
如需進一步了解我們在保護應用程式密鑰和用戶存取憑證（包括您可能需要提供的任何證明）方面的要求，請參閱保護 Meta 應用程式密鑰和存取憑證。
我被問及如何管理和維護帳戶。Meta 的要求是什麼？
- 您可能收到跟進問題，詢問您的機構是否設有管理帳戶和某些相關程序的系統。這個問題亦可能會以編號 Q16 表示。
- 您必須建立工具或程序，以向您機構用作機構內部溝通、開發與發佈軟件及管理系統／應用程式的應用程式和系統授予及撤銷存取權，前提是這些應用程式和系統適用於處理平台資料。
- 您必須至少每 12 個月制定一套程序來審查之前授予的存取權，以及撤銷不再需要和不再使用的存取權。
- 您必須建立程序，以便在有人離開機構時立即撤銷其對所有應用程式和系統的存取權。
我被問及如何測試系統／軟件是否有漏洞。Meta 的要求是什麼？
- 您可能收到跟進問題，詢問機構是否會測試系統／軟件是否有漏洞。這個問題亦可能會以編號 Q12 表示。
如果您的機構在雲端環境（例如 AWS、Azure、GCP、Alibaba Cloud、Tencent Cloud ）中處理 Meta 平台資料： - 您必須已透過以下方式測試雲端軟件是否有安全漏洞：
- 對應用程式／系統進行滲透測試或外部掃描；或
- 使用軟件靜態或動態分析安全工具；或
- 推行符合我們要求的漏洞披露計劃
- 您必須已透過以下方式測試雲端資產配置是否有漏洞：
- 雲端託管商提供的工具；或
- 其他商務或開放來源工具；或
- 推行符合我們要求的漏洞披露計劃
- 如果雲端配置審查不適用於您的機構，您必須在提交的證明中說明具體原因
- 您必須證明上述兩項活動在過去 12 個月內進行。
- 您必須已透過以下方式測試伺服器軟件是否有安全漏洞：
- 對應用程式／系統進行滲透測試或外部掃描；或
- 使用軟件靜態或動態分析安全工具；或
- 推行符合我們要求的漏洞披露計劃
如果您的機構在以不同方式託管的伺服器環境中處理 Meta 平台資料：
對於所有其他機構：
- 您必須已透過以下方式測試用戶端軟件是否有安全漏洞：
- 進行滲透測試或外部掃描；或
- 使用靜態或動態分析安全性工具；或
- 推行符合我們要求的漏洞披露計劃
- 您必須證明此活動在過去 12 個月內進行。
如需更多資訊（包括您可能需要提供的任何證明），請參閱我們的開發人員文件：測試應用程式與系統以查看是否有漏洞和安全問題。
我被問及如何持續更新系統。Meta 的要求是什麼？
- 您可能收到跟進問題，詢問您的機構是否設有持續更新系統程式碼和環境的系統。這個問題亦可能會以編號 Q17 表示。 您必須展示一個明確且可重複進行的程序，以：
- 識別可解決安全漏洞且與用作處理 Meta 平台資料相關的修補程式，
- 視乎風險優先選用這些修補程式；以及
- 持續性套用修補程式。
詳情請參閱我們的開發人員文件：持續更新軟件。
請注意，這些常見問題旨在提供實用的資訊和連結，協助您遵守 DPA 的要求，但我們對 DPA 的評估需受資料安全要求監管。常見問題僅作指南用途，不應被解讀為抵觸或取代有關要求。