Meta 應用程式開發
返回中文(台灣)
這份文件已更新。
中文(台灣) 的翻譯尚未完成。
英文更新時間：4月29日

資料保護評估的常見問題

什麼是資料保護評估

  1. 什麼是資料保護評估？

    1. 資料保護評估是針對存取特定類型資料的應用程式所做的年度評估要求。評估中的問題旨在確定開發人員是否遵守《開放平台使用條款》，因為其與平台資料的使用、分享和保護相關。

  2. 什麼是平台資料？

    1. 「平台資料」係指我們在您同意本條款之前、當下或之後，透過開放平台或您的應用程式直接或間接提供給您的任何資訊、資料或其他內容，包括從這類資料進行匿名處理、彙總或衍生的資料。平台資料包括應用程式權杖、粉絲專頁權杖、存取權杖、應用程式密鑰和用戶權杖。
    2. 您透過應用程式從 Meta 獲得的資料皆為平台資料。舉例來說，用戶編號、用戶電子郵件地址和用戶的朋友都是平台資料。

  3. 該項目與應用程式審查和資料使用情形檢查有何不同？

    1. 應用程式審查是一項前瞻性的程序，能讓您要求批准個別權限與功能。
    2. 資料使用情形檢查則是一年一度的認證程序，供開發商自我確認其透過 Meta API 繼續使用與存取特定資料的行為均遵循我們的《開放平台使用條款》和《開發商政策》。
    3. 資料保護評估是一項年度問卷調查，會詢問開發人員在平台資料方面的資料使用、分享和資料安全。

  4. 我如何為資料保護評估預做準備？

    1. 確保我們能聯繫到您：
      1. 更新您的開發人員或商業帳號聯絡電子郵件和通知設定。
      2. 在應用程式的基本設定頁面更新聯絡電子郵件。
      3. 審查應用程式中所列的管理員，並考慮將您的法律和資料安全團隊成員新增為管理員，以便他們也能回答問題。
    2. 審查資料保護評估中的問題，並與您的團隊針對如何最有效地回答這些問題進行互動。
    3. 審查我們的《開放平台使用條款》和《開發商政策》。

為什麼必須進行資料保護評估

  1. 為什麼我需要完成資料保護評估？

    1. 隨著不斷變化的隱私法規環境以及持續演變的用戶隱私威脅，我們都有責任為使用我們產品和服務的用戶建立信任，而首先是確保其資料在網路上使用、分享和保護的方式。
      1. 開發人員若擁有會存取平台上特定類型資料的應用程式，就必須進行資料保護評估。
      2. 開發人員依據我們的標準實施全新資料安全措施，已有成功案例可循。我們一起合作，就能提升整體網路的標準，讓世界各地數十億名用戶能信任我們所提供的服務。

程序

  1. 我如何知道自己是否需要完成資料保護評估？

    1. 如果您是需要進行資料保護評估之應用程式的管理員，就會在我的應用程式頁面、應用程式主控板、通知收件匣以及與您開發人員帳號相關之電子郵件中收到通知。
      1. 您將收到一則通知，其中將說明如何完成下列步驟，為評估做準備：
        1. 確保我們能聯繫到您：
          1. 更新您的開發人員或商業帳號聯絡電子郵件和通知設定。
          2. 在應用程式的基本設定頁面更新聯絡電子郵件。
          3. 審查應用程式中所列的管理員，並考慮將您的法律和資料安全團隊成員新增為管理員，以便他們也能回答問題。
        2. 審查資料保護評估中的問題，並與您的團隊針對如何最有效地回答這些問題進行互動。
        3. 審查我們的《開放平台使用條款》和《開發商政策》。

  2. 如何確保我收到與資料保護評估相關的電子郵件通訊？

    1. 如果您是需要進行資料保護評估之應用程式的管理員，就會在我的應用程式頁面、應用程式主控板、通知收件匣以及與您應用程式管理員帳號相關的電子郵件中收到通知。
    2. 如果您是應用程式管理員，請確保我們能聯繫到您：
      1. 更新您的開發人員或商業帳號聯絡電子郵件和通知設定。
      2. 在應用程式的基本設定頁面更新聯絡電子郵件。

  3. 我如何知道自己可以開始進行資料保護評估？

    1. 如果您是需要進行資料保護評估之應用程式的管理員，就會透過下列方式收到通知：
      1. 通知：
        1. 系統會傳送電子郵件到開發人員或商業帳號聯絡電子郵件。請在此處編輯個人開發人員通知設定。
        2. 系統會傳送訊息到應用程式主控板中的通知收件匣。
        3. 系統會透過應用程式主控板傳送通知給應用程式管理員。
      2. 必要動作：
        1. 在我的應用程式頁面中，您將在名為「資料保護評估」的應用程式資訊卡上看到「必要行動」。
        2. 在應用程式主控板中，您將在頂端看到「必要行動」。
        3. 在應用程式的基本設定頁面中，您將看到「資料保護評估」紀錄。

  4. 我能夠詢問有關資料保護評估中涵蓋主題的問題嗎？

    1. 可以。如果您需要釐清資料保護評估中詢問的問題，可以直接聯繫 Meta。
      1. 在資料保護評估中，您會在左側看到標題為「需要協助嗎？」的區塊。在此區塊下方點擊「提出問題」就會收到彈出視窗，您可以透過該視窗提交釐清的問題。
      2. 若要使用這項功能，您必須擁有企業管理平台帳號，並務必加入應用程式與應用程式管理員。請參閱下列連結，以取得逐步指南。
      3. 您將透過電子郵件通知以及應用程式主控板中的通知收到 Meta 的回覆。
    1. Meta 在開發人員文件網站上發佈了資料安全規定，但此內容僅供登入 Facebook 帳號的用戶存取。如果您無法開啟此頁面並存取文件，請確認您已經完成下列操作：
      1. 登入 Facebook 帳號。
      2. 在這裡接受 Facebook 的開發人員使用條款。

提交

  1. 我有多少時間可以提交資料保護評估？

    1. 您有 60 天的時間（從首次收到通知起算）來完成資料保護評估。

  2. 我需要多久提交一次資料保護評估？

    1. 這是一項一年一度的要求。

  3. 問卷調查非常長，我可以將其儲存並分成多次完成嗎？

    1. 可以。表格會自動儲存，您能從上次中斷的地方繼續填寫。

  4. 我要如何知道提交的狀態？

    1. 以下針對評估的各項情況說明定義：
      1. 尚未開始：開發人員收到通知，表示需要進行資料保護評估，設有期限，但開發人員尚未開始填寫表格。
      2. 已過期：提交資料保護評估表格的期限已過。開發人員必須完成評估，否則應用程式將受到限制。
      3. 已提交，需要更多資訊：開發人員已提交資料保護評估的答案，Meta 已開始審查，並需要詳細說明。
      4. 已提交，發現違規情形：開發人員已提交資料保護評估的答案，Meta 已開始審查，並確認應用程式違反一或多項《開放平台使用條款》。根據違規的嚴重程度，可能有機會在對程式施以限制之前，解決違規情形。然而如遇到最嚴重的違規情形，則不會給予警告期間。
      5. 已提交，審查中：開發人員已提交資料保護評估的答案，或已回覆提供更多資訊的要求。Meta 已開始審查。評估尚未完成。
      6. 已提交，未發現違規情形：開發人員已提交資料保護評估的答案，Meta 已完成審查，並判斷應用程式符合《開放平台使用條款》。無需再採取其他行動。

  5. 我去年做過這項評估，我可以在哪裡下載答案？

    1. 很抱歉，您無法下載先前評估中的答案，因為我們已變更問卷調查，以提供更明確的資訊。提交本評估的答案後，您將能查看提交資料並下載為 PDF。

審查

  1. Meta 審查人員是否會在作出任何形式的處置之前向我提出其他問題？

    1. 若根據您的回覆，Meta 審查人員需要更多資訊，我們會聯絡您並提出釐清的問題，而您將透過以下方式收到通知：
      1. 通知：
        1. 系統會傳送電子郵件到開發人員或商業帳號聯絡電子郵件。請在此處編輯個人開發人員通知設定。
        2. 系統會傳送訊息到應用程式主控板中的通知收件匣。
        3. 系統會透過應用程式主控板傳送通知給應用程式管理員。
      2. 必要動作：
        1. 在我的應用程式頁面中，您將在名為「資料保護評估」的應用程式資訊卡上看到「必要行動」
        2. 在應用程式主控板中，您將在頂端看到「必要行動」
      3. 狀態：必要行動

  2. 我收到一封電子郵件，表示 Meta 需要更多資訊。為什麼呢？

    1. Meta 審查人員需要仔細判定應用程式是否符合《開放平台使用條款》，而這是個能讓您與審查人員合作的好機會。

  3. 我如何回覆 Meta 審查人員的問題？

    1. 您收到的通知（如上所述）將包含評估連結，而您將在該處的頁面頂端看到資訊，其中詳細介紹 Meta 審查人員在尋找的其他資訊。請在表格中回覆，並視需求上傳文件。請確保在完成回覆後點擊「提交」。

  4. 我有多少時間可以回覆 Meta 審查人員的問題？

    1. 若您收到「需要更多資訊」的要求，您將有 5 個工作天的時間可以回覆。若您未在最初的 5 天期間內回覆，將會收到兩次自動延期，總共 15 個工作天。

回覆違規情形

  1. 我的應用程式會因違反《開放平台使用條款》而受到限制嗎？

    1. 可以。根據違規情形，系統可能會對應用程式進行不同的限制。

  2. 如果發現有違規情形，Meta 審查人員會聯絡我嗎？

    1. 可以。如果根據您對評估的回覆，Meta 審查人員發現違規情形，您將透過下列方式收到通知：
      1. 通知：
        1. 系統會傳送電子郵件到開發人員或商業帳號聯絡電子郵件。請在此處編輯個人開發人員通知設定。
        2. 系統會傳送訊息到應用程式主控板中的通知收件匣。
        3. 系統會透過應用程式主控板傳送通知給應用程式管理員。
      2. 必要動作：
        1. 在我的應用程式頁面中，您將在應用程式資訊卡上看到「必要行動」
          1. 若違規情形是出於未在期限前提交評估，資訊卡會顯示「資料保護評估：已過期」
          2. 若已提交資料保護評估並發現違規情形，資訊卡會顯示「發現違規情形」
        2. 在應用程式主控板中，您將在頂端看到「必要行動」
      3. 狀態：發現違規情形

  3. 如果不回覆，會發生什麼情況？

    1. 不回覆會認定為違反《開放平台使用條款》。
      1. 不回覆的 60 天後，您的應用程式將會停用。
        1. 可透過完成並提交評估來還原應用程式。
        2. 若您收到「需要更多資訊」的要求，您將有 5 個工作天的時間可以回覆。若您未在最初的 5 天期間內回覆，將會收到兩次自動延期，總共 15 個工作天。15 個工作天後，系統將執行您的應用程式。
        3. 若您已超過這些時限，應用程式可能會受到限制。您可以前往我的應用程式頁面，以瀏覽任何因違規而受到限制的應用程式。
          1. 根據違規的嚴重程度，可能有機會在對程式施以限制之前，解決違規情形。然而如遇到最嚴重的違規情形，則不會給予警告期間。若要解決違規情形，請參閱我的應用程式頁面上的「解決」連結，並安裝所述步驟進行操作。

  4. 我如何申請延長回覆違規情形？

    1. 對於每項違規情形，若回覆的期限在 3 天內，就會出現「申請延長時間」按鈕。您可以申請兩次長度等同於警告期間的延長（視違規情形而定），系統將自動核准。

  5. 我如何解決從資料保護評估中發現的違規情形？

    1. 如果發現有違規情形，而應用程式已受到限制，您能以回覆方式提交已修補違規情形的證據，從而解決違規情形。一旦提交回覆，Meta 審查人員將對此進行審查，並在「解決違規情形」表格中直接回覆。

《開放平台使用條款》3（資料使用）

  1. 我應用程式或用戶所位於的司法管轄區並無要求我在用戶請求時刪除用戶資料的適用法律（例如歐盟或加州）。根據 Meta 政策規定，我的應用程式是否仍需要尊重用戶的刪除請求？而我是否仍需要在隱私政策中加入有關用戶如何請求刪除的指示？

    1. 是的。即使應用程式或您用戶所位於的司法管轄區並未要求您在用戶請求刪除用戶資料時進行刪除，我們的《開放平台使用條款》仍要求您：1）在用戶要求刪除平台資料時進行刪除；2）在隱私政策中解釋用戶如何請求刪除其資料 — 除非有適用法律阻止您遵循上述兩項 Meta 規定。

  2. 我的公司使用平台資料來讓用戶在約會交友應用程式中挑選想要的配對條件，或對某些內容（例如酒類銷售）進行年齡限制，避免未成年用戶接觸。這是否代表我們使用平台資料來根據種族、族裔、膚色、國籍、宗教、年齡、性別、性傾向、性別認同、家庭狀況、身心障礙、健康狀況或遺傳性疾病，使某些用戶蒙受不利？

    1. 不，在資料保護評估中，使用平台資料來讓用戶在約會交友應用程式中設定條件或對內容進行年齡限制，並不會被當作根據種族、族裔、膚色、國籍、宗教、年齡、性別、性傾向、性別認同、家庭狀況、身心障礙、健康狀況或遺傳性疾病，而使某些用戶蒙受不利。

  3. 如果我的應用程式因我們無法自動刪除資料而未在某些或所有 Meta 要求的情況下刪除平台資料，會發生什麼情況？

    1. 刪除不一定要自動完成。在回答資料保護評估中有關您是否在某些情況下刪除平台資料的問題時，若您的政策是手動或自動刪除，請予以肯定的答覆。

  4. Meta 使用條款要求我在用戶使用我的應用程式刪除其帳號時，刪除該用戶的平台資料。然而，由於我的應用程式缺少得知用戶何時刪除其 Facebook 帳號所必要的回呼功能，因此無法執行此操作。這是否代表我的應用程式違反 Meta 使用條款？

    1. 不，這並不代表應用程式違反 Meta 使用條款。不需要回呼功能。然而，如果您確實有回呼功能，就必須在用戶刪除其 Facebook 帳號時刪除平台資料。您也必須在用戶刪除其應用程式內部帳號時刪除平台資料。

《開放平台使用條款》4（隱私政策）

  1. 我應用程式的隱私政策包含一項聲明，告知用戶他們可以請求刪除其資料。這樣做足夠嗎？

    1. 只有這項聲明並不足夠，必須包含用戶如何向您提交請求的相關指示。

《開放平台使用條款》5（服務供應商和技術供應商）

  1. 什麼是服務供應商？

    1. 服務供應商係指您提供與開放平台或任何開放平台資料相關的服務時所使用的實體。Google Cloud 和 Amazon Web Services（AWS）為常見的大型服務供應商。

  2. 什麼是子服務供應商？

    1. 子服務供應商係指其他服務供應商所使用的服務供應商，以向前者提供平台或任何平台資料相關服務。

  3. 什麼是技術供應商？

    1. 技術供應商係指主要用途在於協助用戶存取和使用開放平台或開放平台資料的應用程式開發商。一般而言，技術供應商的主要用途在於協助用戶存取和使用 Meta for Developers 或平台資料。

  4. 何謂問題 4 所述的用於「其他」目的之書面合約？

    1. 書面合約的範例包括服務條款、標準非協商協議或已簽署的合約。

《開放平台使用條款》6（資料安全）

  1. 我該採取哪些動作來證明遵守 Meta 的資料安全《開放平台使用條款》第 6.a.i 條？

    1. 為證明遵循規定，我們將詢問您是否有來自第三方稽核人員的資訊安全憑證。擁有此類憑證並非強制規定，但它是證明遵循規定的方法之一。我們也將詢問您實作的特定保護措施。Meta 將使用我們的內部條件來評估您的回覆；如果我們有進一步的問題或要求您指定其他保護措施，將會與您聯絡。

  2. 我是否需要取得第三方稽核單位提供的資訊安全框架（ISF）或網路安全框架（CSF）認證？

    1. 否，您不需要取得稽核單位的認證。擁有 SOC 2、ISO 27001、ISO 27018 或 PCI DSS 認證的組織可提交任何一項以作為證據。
      1. 該認證必須與儲存或處理平台資料的運算環境相關。
    2. 請注意，無論您是否提交安全認證，我們都將詢問您實作的特定保護措施。

  3. 如果我沒有提交安全認證，會需要回答哪些關於資料安全保護的問題？

    1. 針對需要完成資料保護評估的所有開發人員，我們將會詢問是否已實作下列各項：
      1. 針對所有平台資料儲存空間（例如：所有資料庫檔案、備份、物件儲存區）執行待用資料加密
      2. 技術及／或管理控制項，以保護儲存於組織裝置（例如，遺失或遭竊的筆記型電腦或卸除式媒體）的平台資料。各種控制項均可接受，例如：含年度培訓的書面政策文件或告知平台資訊不應儲存於此類裝置的提醒，或是技術控制項。
      3. 針對用於傳輸平台資料的所有公用網路連線，啟用 TLS 1.2 或以上版本的加密處理
    2. 此外，針對有權存取較高風險資料的應用程式開發人員，我們也會詢問是否已實作下列額外安全保護措施：
      1. 至少每 12 個月測試一次應用程式和系統的漏洞及安全問題
      2. 保護憑證和存取權杖等敏感資料
      3. 測試用於處理資料安全事件（例如資料外洩和網路攻擊）的系統和程序
      4. 對遠端存取要求多重驗證
      5. 設有一套系統以維護帳號（指派、撤銷、審查存取權限）
      6. 設有一套系統以確保系統程式碼和環境保持在最新狀態，包括伺服器、虛擬機器、發佈服務、資料庫、套件和防毒軟體
      7. 注意：這份清單並未完整列出所有項目，也無法替代您組織適用的資訊安全計畫。

  4. 系統詢問我的組織是否針對所有平台資料儲存空間執行待用資料加密。這個問題的範圍為何？是否同時適用於雲端和用戶端儲存空間？

    1. 待用資料加密能讓資料在沒有單獨解密金鑰的情況下無法辨識，從而保護平台資料。這能提供另一層的保護，避免未授權的讀取存取。
    2. 在伺服器或雲端環境中（與應用程式所有用戶相關的平台資料多半聚集於該處），待用資料加密能降低資料洩漏的風險。舉例來說，待用資料加密能防止未授權存取資料庫備份等威脅（其保護程度可能不如生產資料庫本身）。
    3. 若貴組織的確在雲端儲存平台資料，您「必須」使用待用資料加密或合適的補償性控制項來保護該資料。我們接受應用程式層級（例如軟體對資料庫中的特定欄位加密／解密）或全磁碟加密。雖然我們建議使用業界標準加密（例如 AES、BitLocker、Blowfish、TDES、RSA），但並未要求任何特定演算法或密鑰長度。
    4. 若貴組織「並未」在雲端儲存平台資料，則此要求並不適用。
    5. 為免疑慮，網路或行動用戶中針對您服務的個別用戶持續留存的資料不在此問題的範圍內。
    6. 若貴組織透過雲端 IaaS 產品（例如 AWS EC2、Microsoft Azure IaaS 和 Google Compute Engine）來儲存平台資料，或您使用代管或混合型手法，則此問題適用。
    7. 然而，有其他幾項後端代管模型為特殊案例：使用 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）來儲存平台資料，則此問題並不適用。您應改於資料保護評估的服務供應商部分說明此關係。

  5. 系統詢問我如何防止平台資料儲存於組織和個人裝置。你們接受哪些類型的防制措施？

    1. 開發人員必須擁有技術及／或管理控制項（例如政策和規則），以保護儲存於組織裝置（例如，可能遺失或遭竊的筆記型電腦或卸除式媒體）的平台資料。各種控制項均可接受，例如：含年度培訓的書面政策文件或告知平台資訊不應儲存於此類裝置的提醒，或是技術控制項。

  6. 系統詢問我的組織是否針對用於傳輸平台資料的所有網路連線，啟用 TLS 1.2 或以上版本。這個問題的範圍為何？

    1. 此問題與任何透過網路傳輸的資料（包括平台資料）相關，無論該傳輸是由網頁或行動用戶至您的雲端環境，或在橫跨網路的雲端環境之間傳輸。
    2. 橫跨網路傳輸的平台資料可由任何能夠觀察網路流量的用戶存取，因此必須加密保護，以防止未授權的各方讀取資料。傳輸中資料加密能讓平台資料除了來源和目的地裝置之外無法辨識，從而在不受信任的網路（例如網際網路）中傳輸平台資料時保護其安全。換言之，處於傳輸當中的各方即使能看到網路流量（又稱為中間人攻擊）也無法讀取平台資料。TLS 是最普遍的傳輸中資料加密，這是瀏覽器用於保障與銀行等網站進行通訊的技術。
    3. 下圖說明可能涉及平台資料傳輸的網路連線。黃色虛線代表您有責任使用 TLS 加密來保障的連線。
      若是完全在私密網路內傳輸的資料，例如 AWS 或 GCP Virtual Private Cloud（VPC），建議使用 TLS，但非必要。
      下表彙總 Meta 開放平台資料傳輸的 TLS 加密需求。
      連線TLS 政策

      往來於終端用戶裝置（行動電話、PC、平板電腦等）以及您的伺服器或雲端基礎架構

      必須針對相容裝置啟用 TLS 1.2 或以上版本

      可啟用 TLS 1.0 和 1.1 以相容舊版裝置

      往來於您的伺服器或雲端基礎架構以及任何遠端伺服器、雲端基礎架構或第四方服務

      必須執行 TLS 1.2 或以上版本

      完全在私密資料中心、伺服器或雲端基礎架構內往來元件

      建議使用 TLS 加密，但完全在私密雲端網路內的開放平台資料傳輸則不需要 TLS 加密

      往來於 Facebook 以及任何裝置、伺服器或雲端基礎架構

      不在資料保護評估的範圍內 - Facebook 控管這些傳輸的 TLS 政策

      請諮詢所屬組織的首席資訊安全官（CISO）或同等職位，或是合格的網路安全公司，指導您為應用程式進行適當的加密和其他補償控制措施。

  7. 系統詢問我的組織是否至少每 12 個月測試一次應用程式和系統的漏洞及安全問題。可接受哪些類型的測試？

    1. 存取 Meta 開放平台的應用程式開發人員會編寫軟體來存取和處理平台資料，並向使用軟體的用戶提供服務。本軟體（和相關系統配置）可能包含有心人士會利用的安全性漏洞，導致對平台資料進行未授權的存取。因此，開發人員必須對漏洞和安全問題進行測試，以便主動發現這些問題，最好是在安全事件發生之前就予以預防。
    2. 在應用程式的整個生命週期中，應執行各種形式的安全測試。通常會採用從簡單的漏洞掃描、應用程式安全掃描，再到滲透測試等多種測試方法的組合，尤其是在處理個人資訊等敏感資料時。
    3. 您必須先對用於處理平台資料的軟體進行安全性漏洞測試，方法為執行滲透測試或漏洞掃描／靜態分析。測試的結果必須顯示沒有未解決的極度或高度嚴重漏洞。測試必須是在過去 12 個月內完成。
    4. 此外，若貴組織在雲端處理平台資料，則可接受的安全性漏洞測試必須特別測試雲端軟體的安全性漏洞，方法為執行以下任一操作：對應用程式／系統進行滲透測試，或漏洞掃描／靜態分析。您也必須對測試雲端配置的安全問題。此要求適用於任何代管方法（BaaS、PaaS、IaaS、自我代管或混合式）。

  8. 系統詢問我的組織是否保護憑證和存取權杖等敏感資料。這個問題的範圍為何？

    1. 應用程式密鑰和存取權杖對 Meta API 的安全而言非常重要，因為它們會對透過這些 API 提供的資料進行存取控制。若未授權的一方獲得存取這些憑證的權限，就能呼叫 Meta 的 API（假冒真正的開發人員），並採取任何我們授權該應用程式的行動（例如讀取 API 中有關某個應用程式用戶的資料）。
    2. 作為 Meta 平台使用行為的一環，開發人員可以存取敏感憑證。具體項目如下：
      1. 應用程式密鑰 - Meta 會與開發人員分享應用程式密鑰，並期望只有開發人員組織中受信任的各方（例如應用程式管理員）擁有存取此密鑰的權限
      2. 存取權杖 - 當用戶授權一個應用程式時，開發人員會獲得一個稱為存取權杖的憑證，該憑證會用於隨後的 API 呼叫
    3. 能夠讀取這些敏感憑證的未授權方可將其用於呼叫 Meta API，就如同他們是開發人員一般（此行為有時稱為權杖假冒），導致對平台資料進行未授權的存取。因此，這些憑證必須獲得保護，以防止未授權的存取，避免假冒行為。
    4. 應用程式密鑰 - 必須落實以下兩項作法中的其中一項：
      1. 開發人員從未在安全的伺服器環境以外之處暴露應用程式密鑰（例如，該項目從未遭網路呼叫退回至瀏覽器或行動應用程式，且密鑰並未嵌入分發至行動或原生／桌上型電腦用戶的代碼）
      2. 或者，開發人員必須將其應用程式配置為原生／桌上型電腦類型，這樣我們的 API 將不再信任保護應用程式密鑰的 API 呼叫
    5. 存取權杖 - 必須落實以下所有作法：
      1. 在用戶端裝置上 - Meta 存取權杖不得編寫為可由其他用戶或程序讀取
      2. 在雲端中 - 若開發人員在雲端處理或儲存 Meta 存取權杖，則這些存取權杖：
        1. 必須受儲存庫或應用程式加密保護，其中存取解密金鑰的權限僅限應用程式，且不得寫入紀錄檔案
        2. 或必須受合適的補償性控制項保護

  9. 系統詢問我的組織是否至少每 12 個月測試一次我們的安全事故應變系統和程序。這個問題的範圍為何？

    1. 所有公司遲早都會發生安全事件，因此組織必須提前規劃如何控制事件、與利害關係人溝通、從發生的事情中恢復和學到經驗，並安排執行上述事項的人員。若發生安全事件，準備好計畫或教戰手冊（並擁有針對負責事項進行培訓的團隊）將能減少事件的時間長度，最終限制平台資料的暴露程度。
    2. 雖然組織不同，事件應變的複雜程度也不同，但我們需要至少一項基本計畫，其中包括關鍵活動：偵測、做出反應、恢復和審查，以及指定人員的分派角色和責任。您也應持有文件證據，證明該計畫最近（過去 12 個月內）曾進行測試，且所有計畫中提及的人員均確實參與測試。

  10. 系統詢問我的組織是否需要對遠端存取進行多重驗證。這個問題的範圍為何？

    1. 不肖分子用於獲得機密資料存取權限的一種常見技術，是先行獲得存取開發人員用於打造或操作其應用程式／系統之工具的權限。有複雜的工具可取得用戶憑證（例如釣魚攻擊）以駭入僅由密碼保護的帳號；而多重驗證能提供另一層的保護，防範此類風險。
    2. 軟體開發人員會使用各種工具來打造、部署和管理其應用程式／系統。通常會透過網路由遠端使用這類工具（例如，一名員工在家工作，並傳送新的軟體功能或更新雲端配置）。使用單一驗證（用戶名稱和密碼）保護的工具極易受到帳號接管攻擊。舉例來說，攻擊者可能會使用工具來嘗試洩漏自一項工具的用戶名稱和密碼組合，以獲得存取另一項工具的權限。多重因素認證會在登入時要求密碼之外的其他因素（例如驗證器產生的代碼），從而防止此類攻擊。
    3. 由於攸關組織的平台資料處理，因此遠端存取此類工具的權限必須以多重驗證（亦即不僅僅依靠單一密碼）保護：
      1. 用於部署和管理應用程式／系統的代碼／配置變更的工具
      2. 雲端或伺服器環境的管理權限（如適用）
      3. 具體項目如下：
        1. 合作／通訊工具 - 例如公司電子郵件或 Slack
        2. 代碼儲存庫 - 例如 GitHub 或另一項用於追蹤應用程式／系統的代碼／配置變更的工具
      4. 以及如果組織在雲端／伺服器環境中處理平台資料：
        1. 軟體部署工具 - 用於將代碼部署至雲端／伺服器環境的工具，例如 Jenkins 或其他持續整合／持續部署（CI／CD）工具
        2. 管理工具 - 入口網站或其他用於管理／監控雲端或伺服器環境的存取工具
        3. 遠端存取伺服器 - SSH、遠端桌上型電腦，或用於遠端登入在雲端或伺服器環境中運作之伺服器的類似工具

  11. 系統詢問我的組織是否有用於維護帳號（指派、撤銷、審查存取內容和權限）的系統。這個問題的範圍為何？

    1. 擁有良好的帳號管理衛生是防止未授權使用帳號以獲得存取平台資料之權限的重要環節。開發人員尤其必須確保於不再需要存取資源或系統的權限時予以撤銷。帳號是授予用戶存取系統、資料和管理功能之權限的基本管理單位。帳號會獲得進行特定動作的權限；良好的做法是僅授予帳號所需的最低權限，這稱為最低權限原則。
    2. 當用戶離開組織時，基於下列幾項原因，務必及時停用其用戶帳號：
      1. 為避免該用戶（亦即前員工）進行存取，以及
      2. 為降低未授權用戶在不被注意的情況下使用該帳號的可能性。舉例來說，有心人士可能會使用社交工程來促使 IT 客服中心重設帳號的密碼。若此帳號為一名在職員工所有，該員工可能會回報無法登入，而如果該帳號屬於一名已離職的員工卻仍然有效，就很有可能不被注意到。
    3. 考量到這一點，組織必須擁有系統化的方式來管理帳號、授予權限或特權，並於不再需要存取權限時予以撤銷
    4. 開發人員必須擁有一項工具或程序來管理下列每項工具／系統／應用程式的帳號：
      1. 用於彼此溝通的項目（例如 Slack 或公司電子郵件）
      2. 用於傳輸軟體的項目（例如代碼儲存庫），以及
      3. 管理並操作其系統（如適用於處理平台資料）
    5. 開發人員定期審查（亦即不少於每 12 個月一次）存取權限授權，並擁有在下列情況下撤銷存取權限的程序：（1）不再需要存取權限時，以及（2）不再使用存取權限時
    6. 他們也必須擁有一項程序，能在用戶離開組織時及時撤銷存取這些工具的權限

  12. 系統詢問我的組織是否設有一套系統以確保系統程式碼和環境保持在最新狀態，包括伺服器、虛擬機器、發佈服務和防毒軟體。這個問題的範圍為何？

    1. 系統會定期更新或修補軟體元件，以解決安全性漏洞，而最終這些元件會在不受支援時達到其使用壽命。打包或依賴這些元件的開發人員必須隨時掌握最新消息，以避免執行有已知漏洞的軟體。
    2. 應用程式開發人員依賴各種第三方軟體來執行處理平台資料的應用程式／系統。例如，開發人員將依賴下列部分或全部項目：
      1. 資料庫、SDK、套件 - 開發人員會將這些項目與自己的自訂代碼打包，以打造應用程式
      2. 虛擬機器圖像、應用程式容器和作業系統 - 應用程式會在其中一個或多個容器中執行；這些容器提供數項服務，例如虛擬化以及存取網路和儲存空間的權限
      3. 開發人員的員工／協作者使用的瀏覽器、作業系統和其他應用程式 - 在開發人員用來打造並執行其系統的行動裝置和筆記型電腦上執行的軟體
    3. 這些元件中經常發現安全性漏洞，從而導致發佈修補。藉由修補修復的漏洞隨後會在公開資料庫中揭露，並標明嚴重性評級（輕度、中度、重度或極度）。因此，我們平台的開發人員必須擁有系統化的方式來透過下列方法管理修補：
      1. 找出與其應用程式／系統相關的修補
      2. 根據曝光率排定急迫性的優先順序，以及
      3. 將施加修補作為一項持續進行的業務活動
    4. 對於下列軟體元件，依適用情況而定，開發人員必須擁有系統化的方式來找出能解決安全性漏洞的可用修補、根據風險排定優先順序，並將施加修補作為一項持續進行的業務活動：
      1. 在雲端或伺服器環境中使用的資料庫、SDK、套件、應用程式容器和作業系統
      2. 在用戶端裝置上（例如行動應用程式中）使用的資料庫、SDK、套件
      3. 組織成員用來打造並執行其應用程式／系統的作業系統和應用程式，例如在員工的筆記型電腦上執行的作業系統和瀏覽器

  13. 如果我沒有上述一或多項安全控制措施，但已實作補償性安全控制措施，我該怎麼做？

    1. 如果您認為 Meta 要求您執行的其中一個控制項對您使用（例如儲存或處理）Meta Platform 資料的行為沒有意義，或者您正在對其中一項或多項保護措施實施補償性控制項，請說明您的情況並提供證據以解決違規情形。若您收到我們有關遵循規定的電子郵件，應該按照電子郵件中的指示於應用程式主控板中作出回覆。若您無法找到電子郵件通知，請前往我的應用程式頁面或該應用程式的應用程式主控板。

  14. 系統詢問我是否有公開管道讓用戶向我們回報安全性漏洞。我需要有特定管道來處理此問題嗎？

    1. 雖然我們的政策並未要求擁有回報安全性漏洞的單獨管道（任何定期監控的聯絡資料，例如電子郵件地址、聯絡表格或電話都合乎規定），但我們建議開發人員為此目的制定結構化程序，例如在 BugCrowd 或 HackerOne 上執行「安全漏洞揭露計畫」（VDP）。

  15. 我在 DPA 審查團隊傳來的通訊中看到一個問題參考編號。這些編號是指什麼？

    1. 您可能會在我們審查團隊傳來的通訊中看到一個問題參考編號。這些編號主要用於內部審查程序，但若您想瞭解，這裡提供該參考資訊：
      1. Q9 - 雲端或伺服器環境中的待用資料加密。
      2. Q10 - 保護組織或個人裝置上的平台資料。
      3. Q11 - 使用傳輸中資料加密來保護平台資料。
      4. Q12 - 測試應用程式和系統是否有安全性漏洞。
      5. Q13 - 保護 Meta 應用程式密鑰和存取權杖。
      6. Q14 - 設有事件應變計畫並測試事件應變系統和程序。
      7. Q15 - 對遠端存取要求多重驗證。
      8. Q16 - 設有用於維護用戶帳號的系統。
      9. Q17 - 將軟體保持在最新狀態。

  16. 我收到 DPA 審查團隊的意見回饋，指出政策或程序證據缺漏或不充分。什麼是政策或程序證據？

    1. 您可能會收到後續追蹤問題，詢問您有關一或多個資料安全問題的相關政策或程序證據，Meta 審查團隊可能以下列其中一個編號來指出問題：Q9、Q10、Q11、Q12、Q13、Q14、Q15、Q16 和 Q17。

      在上述所有情況下，政策或程序證據是指一種書面文件，其中說明您組織用來實作特定資料安全保護措施的方法。例如，您的組織可能有下列書面文件：
      1. 驗證政策文件，明確規定所有可能存取平台資料的商業、開發和系統管理工具，都必須使用多重驗證來保護。
      2. 加密政策，明確規定所有 Meta 開放平台資料都必須使用傳輸中資料加密和待用資料加密來保護。
      3. 修補程序，列出必須執行這些步驟的頻率，以定期識別會影響組織雲端應用程式的任何可用安全修補程式；如何針對每個修補程式進行影響評估；根據嚴重性制定部署修補程式的最長時間；以及如何部署修補程式。
      這些範例都是相關問題的政策或程序文件的可接受形式。Meta 的 DPA 審查人員會審查您提供的文件，確認您的方法符合我們的要求。如需詳細資訊，包括有關如何準備所要提交之政策證據的其他範例和詳細內容，請參閱我們有關準備證據的開發人員文件。

  17. 我收到 DPA 審查團隊的意見回饋，指出實作證據缺漏或不充分。什麼是實作證據？

    1. 您可能會收到後續追蹤問題，詢問您有關一或多個資料安全問題的相關實作證據。資料安全問題有時會以編號指出，例如 Q9、Q10、Q11、Q12、Q13、Q14、Q15、Q16 和 Q17。

      在所有這些情況下，加入實作證據是重要的，這樣才能證明您已實作明文規定的政策或程序。這些證據可能包括管理系統的截圖和工具的輸出資料，以顯示組織如何實際執行其保護方法。可接受的實作證據必須證明您組織的實作方式符合 Meta 對保護措施的要求。您必須針對每一項保護措施，各提交至少一件實作證據。

      如需詳細資訊，請參閱我們有關針對每一項保護措施準備證據的開發人員文件：
      1. 雲端或伺服器環境中的待用資料加密。
      2. 保護組織或個人裝置上的平台資料。
      3. 使用傳輸中資料加密來保護平台資料。
      4. 測試應用程式和系統是否有安全性漏洞。
      5. 保護 Meta 應用程式密鑰和存取權杖
      6. 設有事件應變計畫並測試事件應變系統和程序。
      7. 對遠端存取要求多重驗證。
      8. 設有用於維護用戶帳號的系統。
      9. 將軟體保持在最新狀態。

  18. 系統詢問我如何保護組織或個人裝置上的平台資料。Meta 的要求是什麼？

    1. 您可能會收到後續追蹤問題，詢問您的組織如何保護儲存在組織或個人裝置上的平台資料，以免資料遺失。這些問題可能也會以編號 Q10a 或 Q10b 指出。

      Meta 要求您至少證明下列其中一項：
      1. 您的組織採取措施來阻擋存取包含 Meta 開放平台資料的系統，僅限具有下列一或兩項條件的裝置存取：
        1. 所有裝置都必須啟用全磁碟加密，例如透過 FileVault 或 BitLocker。
        2. 所有裝置都必須執行端點 DLP 軟體，例如 Microsoft Intune 或 Symantec DLP。
      2. 您的組織已制定政策，禁止組織裡的任何人將 Meta 開放平台資料儲存在任何組織或個人裝置上，而且您有證明組織成員有義務遵守此政策的書面證據。
      3. 您的組織具有明確規定下列事項的政策：
        1. 僅限需要存取且有經授權之商業用途的個人，才能在組織裝置上處理平台資料，並且
        2. 當經授權之商業用途不存在時，個人必須將平台資料從這些裝置刪除。
      4. 任何組織成員都不能因為軟體的組建方式（例如，Meta 開放平台資料只儲存在終端顧客裝置的暫存記憶體中），而得以存取 Meta 開放平台資料

  19. 什麼是 Facebook 或 Meta 應用程式密鑰？

    1. 您可能會收到後續追蹤問題，詢問您如何保護 Facebook 或 Meta 應用程式密鑰。這個問題可能也會以編號 Q13 指出。

      應用程式密鑰是與 Facebook 應用程式相關聯的參數，可在某些 API 呼叫中用作存取權杖，以變更應用程式配置，例如配置 Webhook 回呼。您可以在開發人員主控板的「設定」>「基本」底下找到您應用程式的 Facebook 應用程式密鑰。如需應用程式密鑰的詳細資訊，請參閱我們有關登入安全性的開發人員文件。

      若要進一步瞭解我們針對保護應用程式密鑰和用戶存取權杖的相關規定，包括您可能需要提供的任何證據，請參閱保護 Meta 應用程式密鑰和存取權杖。

  20. 系統詢問我如何管理和維護帳號。Meta 的要求是什麼？

    1. 您可能會收到後續追蹤問題，詢問您的組織是否設有一套系統，以管理帳號和某些相關程序。這個問題可能也會以編號 Q16 指出。
      1. 針對您的組織用來在組織內部通訊、開發和傳送軟體，以及管理系統／應用程式的應用程式和系統，只要與處理平台資料有關，都必須有一項工具或程序來授予和撤銷對這些應用程式和系統的存取權限。
      2. 您必須有一個程序，可以審查先前授予的存取權限，以及撤銷不再需要和不再使用的授權，每 12 個月至少審查一次。
      3. 您必須有一個程序，可以在員工離開組織時，立即撤銷其所有應用程式和系統的存取權限。
      如需詳細資訊，包括您可能需要提供之任何證據的相關資訊，請參閱我們的開發人員文件：「 設有用於維護用戶帳號的系統」。

  21. 系統詢問我如何測試系統／軟體是否有漏洞。Meta 的要求是什麼？

    1. 您可能會收到後續追蹤問題，詢問您的組織是否對系統／軟體進行漏洞測試。這個問題可能也會以編號 Q12 指出。

      如果您的組織在雲端環境中（例如 AWS、Azure、GCP、阿里雲、騰訊雲等）處理 Meta 開放平台資料：
      1. 您必須透過下列方式測試雲端軟體是否有安全漏洞：
        1. 應用程式或系統的滲透測試或外部掃描；或
        2. 軟體的靜態或動態分析安全工具；或
        3. 施行符合我們要求的「安全漏洞揭露計畫」
      2. 您也必須透過下列方式測試雲端資產配置是否有漏洞：
        1. 雲端主機提供的工具；或
        2. 其他商業或開放原始碼工具；或
        3. 施行符合我們要求的「安全漏洞揭露計畫」
        4. 如果雲端配置審查不適用於您的組織，您必須在所提出的證據中說明不適用的理由
      3. 您必須證明在過去 12 個月內已進行上述兩項活動。
      Meta 通常會要求所有極度或高度嚴重的漏洞都必須解決。

      如果您的組織是在以不同方式託管的伺服器環境中處理 Meta 開放平台資料：
      1. 您必須透過下列方式測試伺服器軟體是否有安全漏洞：
        1. 應用程式或系統的滲透測試或外部掃描；或
        2. 軟體的靜態或動態分析安全工具；或
        3. 施行符合我們要求的「安全漏洞揭露計畫」
    Meta 通常會要求所有極度或高度嚴重的漏洞都必須解決。

    對於所有其他組織：
    1. 您必須透過下列方式測試用戶端軟體是否有安全漏洞：
      1. 滲透測試或外部掃描；或
      2. 靜態或動態分析安全工具；或
      3. 施行符合我們要求的「安全漏洞揭露計畫」
    2. 您必須證明在過去 12 個月內已進行此活動
    Meta 通常會要求所有極度或高度嚴重的漏洞都必須解決。

    如需詳細資訊，包括您可能需要提供的任何證據，請參閱我們的開發人員文件：「測試應用程式和系統的漏洞及安全問題」。


  22. 系統詢問我如何將系統保持在最新狀態。Meta 的要求是什麼？

    1. 您可能會收到後續追蹤問題，詢問您的組織是否設有一套系統，以確保系統程式碼和環境保持在最新狀態。這個問題可能也會以編號 Q17 指出。
      2. 您必須證明有一個已定義且可重複的程序能夠：
      1. 識別可解決安全漏洞且與您用來處理 Meta 開放平台資料之軟體相關的修補程式、
      2. 根據風險排定這些修補程式的優先順序，以及
      3. 將套用修補程式作為持續進行的活動。
      請務必提供充分的細節，說明您的軟體如何處理平台資料，讓我們能夠驗證您的程序符合上述所有要求。例如，您不能只說明您的組織設有修補伺服器作業系統的程序，而沒有解釋您用於其他堆疊階層（例如虛擬化階層、容器階層、應用程式容器階層、應用程式內的資料庫或相依項目）的方法。

      如需詳細資訊，請參閱我們的開發人員文件：「將軟體保持在最新狀態」。

請注意，這些常見問題旨在提供有用的資訊和連結，以協助您回應 DPA，但「資料安全規定」才是我們評估 DPA 的依據。這些常見問題只是一個指南，不應視為可否定或取代該規定。

瞭解詳情