本指南提供了有關(guān)保護(hù)基于 HTTP 的 API 的建議。它針對(duì)的是負(fù)責(zé)設(shè)計(jì)或構(gòu)建提供 HTTP API 的應(yīng)用程序的技術(shù)人員。請(qǐng)注意，您應(yīng)該針對(duì)您的特定設(shè)計(jì)進(jìn)行威脅建模，以完全保護(hù)基于 HTTP 的 API。

什么是基于 HTTP 的 API？

基于 HTTP 的 API 可實(shí)現(xiàn)不同軟件系統(tǒng)（通常包括第三方服務(wù)）之間的通信，并可用于訪問服務(wù)和數(shù)據(jù)庫、操作數(shù)據(jù)，甚至處理用戶身份驗(yàn)證和授權(quán)。它們是現(xiàn)代互聯(lián)網(wǎng)應(yīng)用程序架構(gòu)中的關(guān)鍵組件。

API（應(yīng)用程序編程接口）通常定義為一組規(guī)范（例如發(fā)送到 API 端點(diǎn)的 HTTP 請(qǐng)求的格式）以及響應(yīng)消息結(jié)構(gòu)的定義，通常為 JSON 格式。API 可用于接收一些數(shù)據(jù)、上傳一些數(shù)據(jù)或控制操作或系統(tǒng)。 

API 面臨的威脅

攻擊者可以通過多種方式利用 API 中的弱點(diǎn)和漏洞。例如，他們可以：

• 使用不安全的 API 端點(diǎn)獲取敏感數(shù)據(jù)
• 使用 API 上傳惡意代碼，并利用它來攻擊系統(tǒng)
• 獲取 API 訪問權(quán)限，然后在系統(tǒng)上執(zhí)行未經(jīng)授權(quán)的操作（例如在銀行系統(tǒng)中進(jìn)行未經(jīng)授權(quán)的付款）
• 使用 API 來操作已存儲(chǔ)在系統(tǒng)中的數(shù)據(jù) 
• 通過反復(fù)輪詢 API 端點(diǎn)發(fā)起拒絕服務(wù)攻擊 

由于基于 HTTP 的 API 在您的組織外部共享，目的是提供數(shù)據(jù)或功能，因此您應(yīng)該執(zhí)行特定于服務(wù)的威脅建模以了解相關(guān)的風(fēng)險(xiǎn)和威脅。

1. 安全開發(fā)實(shí)踐

您的 API 被入侵可能會(huì)影響運(yùn)營、損害組織的聲譽(yù)，甚至可能導(dǎo)致監(jiān)管機(jī)構(gòu)的罰款。在設(shè)計(jì)系統(tǒng)之前確定背景非常重要，因?yàn)檫@將確保任何安全控制措施與您面臨的威脅相稱。例如，用于公共天氣預(yù)報(bào)應(yīng)用程序的 API 和用于管理生產(chǎn)線的 API 具有完全不同的威脅和風(fēng)險(xiǎn)狀況，這將轉(zhuǎn)化為不同的安全控制措施

威脅模型你的設(shè)計(jì)

首先對(duì)高級(jí)設(shè)計(jì)進(jìn)行威脅建模，這樣您就可以在設(shè)計(jì)過程的早期了解任何潛在威脅。NCSC 關(guān)于威脅建模和OSWAP 十大 API威脅的指導(dǎo)可以為您提供幫助。 

使用有據(jù)可查的 API

全面的 API 文檔可以為您的 API 設(shè)計(jì)提供資產(chǎn)管理。這可用于確定：

• 應(yīng)該作為應(yīng)用程序的一部分公開的端點(diǎn) 
• 不應(yīng)暴露的端點(diǎn)（例如開發(fā)或管理端點(diǎn)）
• 遺留端點(diǎn)

良好的文檔將有助于確保將正確的安全控制應(yīng)用于需要它的 API 設(shè)計(jì)部分。嘗試使用常用的 API 規(guī)范（例如OpenAPI）來記錄和描述您的 API。使用社區(qū)理解的 API 規(guī)范允許使用常用工具來可視化和理解您的 API 設(shè)計(jì)。

作為本文檔的一部分，請(qǐng)確保您有效地管理 API 版本，以確保不會(huì)無意中使用已棄用或不安全的版本，并確?？蛻舳耸冀K使用最新的安全版本。通過版本控制，您還可以棄用并最終淘汰不安全或過時(shí)的 API 版本，從而鼓勵(lì)用戶遷移到更新、更安全的版本。

安全開發(fā)和測(cè)試

NCSC 使用“設(shè)計(jì)安全”一詞來描述一種開發(fā)方法，該方法鼓勵(lì)組織將網(wǎng)絡(luò)安全“融入”產(chǎn)品生命周期的所有階段，而不是事后才考慮。無論 API 受到多么好的保護(hù)，仍然需要安全的開發(fā)環(huán)境和代碼交付。一旦投入生產(chǎn)，任何 API 都應(yīng)接受適當(dāng)?shù)陌踩珳y(cè)試，包括適用于威脅模型的負(fù)面測(cè)試和模糊測(cè)試（而不僅僅是正面測(cè)試）。

使用標(biāo)準(zhǔn)

在構(gòu)建使用基于 HTTP 的 API 的應(yīng)用程序時(shí)，請(qǐng)嘗試使用眾所周知的適當(dāng)標(biāo)準(zhǔn)。這可以降低設(shè)計(jì)中出現(xiàn)安全漏洞的可能性。一些示例包括：

• 使用 JSON 進(jìn)行數(shù)據(jù)交換
• 使用 OpenAPI 描述 API 設(shè)計(jì)
• 使用TLS等標(biāo)準(zhǔn)加密技術(shù)來傳輸數(shù)據(jù)

您的 API 設(shè)計(jì)中可以考慮許多其他標(biāo)準(zhǔn)，并且您應(yīng)該優(yōu)先使用已嘗試和測(cè)試的方法，而不是構(gòu)建自己的方法。

資產(chǎn)登記與治理

資產(chǎn)登記冊(cè)和有效治理可以幫助組織保持對(duì)其 API 的可見性、控制力和保護(hù)。資產(chǎn)登記冊(cè)是一份全面的清單，詳細(xì)列出了組織基礎(chǔ)設(shè)施內(nèi)的所有 API 端點(diǎn)、服務(wù)和相關(guān)資源。該登記冊(cè)不僅有助于識(shí)別潛在漏洞，而且還能在整個(gè)生命周期內(nèi)高效地監(jiān)控和管理資產(chǎn)。

有效的治理可確保制定政策、程序和控制措施來保護(hù)這些資產(chǎn)，并符合行業(yè)標(biāo)準(zhǔn)和監(jiān)管要求。 

2. API 認(rèn)證與授權(quán)

實(shí)施強(qiáng)大的身份驗(yàn)證和授權(quán)對(duì)于保護(hù) API 至關(guān)重要，可確保只有合法用戶或服務(wù)才能訪問端點(diǎn)并執(zhí)行操作。身份驗(yàn)證可驗(yàn)證發(fā)出 API 請(qǐng)求的實(shí)體的身份，而授權(quán)可控制經(jīng)過身份驗(yàn)證的實(shí)體可以執(zhí)行哪些操作。

在許多情況下，身份驗(yàn)證和授權(quán)是緊密聯(lián)系的，某些機(jī)制同時(shí)發(fā)揮這兩種功能。例如，身份提供者頒發(fā)的令牌可以對(duì)用戶進(jìn)行身份驗(yàn)證，并包含定義用戶有權(quán)執(zhí)行哪些操作的聲明。

選擇正確的身份驗(yàn)證和授權(quán)方法需要仔細(xì)規(guī)劃并考慮應(yīng)用程序的特定需求。

用戶訪問

應(yīng)用程序通常需要代表用戶與 API 進(jìn)行交互，但傳統(tǒng)的用戶身份驗(yàn)證方法并不適合此目的。與使用用戶憑據(jù)相比，更安全的方法是通過身份提供商進(jìn)行用戶身份驗(yàn)證。此過程會(huì)生成臨時(shí)憑據(jù)（例如令牌或 Cookie），然后應(yīng)用程序可以使用這些憑據(jù)安全地與 API 進(jìn)行交互。

有關(guān)更多信息，請(qǐng)參閱 NCSC 關(guān)于為企業(yè)在線服務(wù)選擇身份驗(yàn)證方法和多因素身份驗(yàn)證的指南

API 身份驗(yàn)證

安全 API 身份驗(yàn)證的良好實(shí)踐包括以下內(nèi)容：

安全的生成和交換

憑證應(yīng)在安全的環(huán)境中生成，最好不要從生成憑證的地方導(dǎo)出。對(duì)于基于公鑰加密的憑證尤其如此。如果需要導(dǎo)出憑證（通常使用對(duì)稱密鑰時(shí)），則必須使用安全傳輸來完成，并且該過程應(yīng)自動(dòng)化，幾乎不需要人工參與。 

避免將憑證直接硬編碼到存儲(chǔ)在版本控制中的源代碼中，尤其是當(dāng)存儲(chǔ)庫可公開訪問或廣泛共享時(shí)。一旦進(jìn)入版本控制，機(jī)密可能很難完全刪除。攻擊者經(jīng)常掃描公共存儲(chǔ)庫以查找此類憑證。

安全憑證存儲(chǔ)

確保您的 API 憑據(jù)已安全存儲(chǔ)。考慮使用機(jī)密管理器（具有安全存儲(chǔ)后端，如 HSM 或云 KMS），或?qū){據(jù)存儲(chǔ)在防篡改硬件支持的存儲(chǔ)位置（例如 USB 令牌或 TPM）。安全性較差的機(jī)密會(huì)增加攻擊者竊取您的憑據(jù)的可能性，尤其是當(dāng)您將機(jī)密存儲(chǔ)在多個(gè)位置時(shí)，這會(huì)使審計(jì)變得困難（此問題稱為“機(jī)密蔓延”）。

對(duì)于短期憑證（或用于對(duì)低價(jià)值應(yīng)用程序進(jìn)行身份驗(yàn)證），您可以使用軟件支持的存儲(chǔ)。您應(yīng)該平衡憑證的有效時(shí)間長度、價(jià)值和使用的存儲(chǔ)方法。

憑證有效期

憑證的有效期應(yīng)設(shè)置為適合用例和威脅的適當(dāng)時(shí)間。憑證到期后應(yīng)自動(dòng)輪換或續(xù)訂，輪換過程應(yīng)自動(dòng)化，無需人工參與。如果憑證無法存儲(chǔ)在安全的存儲(chǔ)方法中，或者憑證不具有抗重放性，則應(yīng)通過縮短憑證的有效期來降低風(fēng)險(xiǎn)。 

避免使用長期訪問密鑰，因?yàn)槿绻荑€被盜用，可能會(huì)授予無限期訪問權(quán)限，從而可能暴露數(shù)據(jù)和服務(wù)。獲得這些密鑰訪問權(quán)限的攻擊者可以濫用您的 API 資源，直到密鑰被輪換或撤銷。使用短期密鑰將縮短攻擊者在密鑰變?yōu)榉腔顒?dòng)狀態(tài)（對(duì)攻擊者毫無用處）之前可以使用密鑰的時(shí)間窗口。

防重放憑證

使用具有防重放保護(hù)的憑證。這可以通過使用基于公鑰加密的憑證來實(shí)現(xiàn)，例如證書或簽名的 JSON Web 令牌 (JWT)。憑證的使用應(yīng)成為任何監(jiān)控策略的一部分，任何濫用行為都應(yīng)發(fā)出警報(bào)。

避免使用弱身份驗(yàn)證方法

不要使用弱身份驗(yàn)證方法，例如基本身份驗(yàn)證或 API 密鑰?；旧矸蒡?yàn)證以 Base64 編碼格式在每個(gè)請(qǐng)求中傳輸用戶名和密碼，而 API 密鑰則放置在 http 標(biāo)頭中并作為共享承載令牌。這兩種方法都很容易受到攻擊，通常是由于機(jī)密管理不善。它們還經(jīng)常提供廣泛的訪問權(quán)限，且不會(huì)過期或限制權(quán)限。您應(yīng)該采用更強(qiáng)大的身份驗(yàn)證方法（例如簽名的 JWT 或證書），這些方法應(yīng)按照 NCSC 指導(dǎo)實(shí)施和管理。 

API 授權(quán)

一旦用戶通過身份驗(yàn)證，控制他們可以執(zhí)行哪些操作以及他們可以在 API 中訪問哪些數(shù)據(jù)就很重要了。授權(quán)根據(jù)請(qǐng)求實(shí)體的身份和權(quán)限來控制對(duì)資源的訪問。除非您托管完全開放的公共 API，否則實(shí)施授權(quán)框架至關(guān)重要。

指導(dǎo)有效授權(quán)治理的三個(gè)基本原則：

1. 強(qiáng)制執(zhí)行最小權(quán)限：授予用戶或進(jìn)程執(zhí)行其任務(wù)所需的最低限度的訪問權(quán)限，從而限制潛在的安全漏洞或惡意活動(dòng)。
2. 默認(rèn)拒絕：默認(rèn)限制訪問，只允許明確授權(quán)的實(shí)體進(jìn)入。
3. 驗(yàn)證每個(gè)請(qǐng)求的權(quán)限：持續(xù)驗(yàn)證系統(tǒng)內(nèi)每個(gè)操作的訪問權(quán)限。

授予令牌過多權(quán)限會(huì)增加數(shù)據(jù)泄露或服務(wù)濫用的風(fēng)險(xiǎn)。這通常是由于使用通用密鑰或范圍過廣的令牌，并擁有對(duì)各個(gè)端點(diǎn)的完全訪問權(quán)限所致。 

OpenID Connect 和 OAuth2.0

OAuth 2.0 和 OpenID Connect (OIDC) 是兩個(gè)互補(bǔ)的行業(yè)標(biāo)準(zhǔn)框架，用于保護(hù) API 訪問和用戶身份管理。您可以使用一系列標(biāo)準(zhǔn)來實(shí)現(xiàn)我們的身份驗(yàn)證和授權(quán)指南。

1. OAuth 2.0 是一個(gè)授權(quán)框架，允許第三方應(yīng)用程序代表用戶訪問資源，而無需暴露其憑據(jù)。它使用令牌促進(jìn)安全的委托訪問，但本身并不提供身份驗(yàn)證。 
2. OpenID Connect 通過引入身份層擴(kuò)展了 OAuth 2.0，該身份層使應(yīng)用程序能夠通過 JWT 驗(yàn)證用戶身份并檢索與身份相關(guān)的聲明。它通過合并 ID 令牌來實(shí)現(xiàn)這一點(diǎn)，該令牌包含有關(guān)經(jīng)過驗(yàn)證的用戶的已驗(yàn)證信息。此擴(kuò)展有助于實(shí)現(xiàn)單點(diǎn)登錄 (SSO)，使用戶能夠安全地訪問多個(gè)應(yīng)用程序，而無需重新輸入憑據(jù)。

OAuth 的最新進(jìn)展引入了改進(jìn)的憑證保護(hù)安全機(jī)制，例如證書綁定令牌和所有權(quán)證明 (DPoP)。盡管這些安全增強(qiáng)功能相對(duì)較新，但它們得到了廣泛支持，并被強(qiáng)烈推薦作為OAuth 2.0 最佳當(dāng)前實(shí)踐 (BCP)指南的一部分，以減輕令牌盜竊和重放攻擊等風(fēng)險(xiǎn)。

3. 傳輸中的數(shù)據(jù)保護(hù)

API 數(shù)據(jù)應(yīng)使用 TLS（傳輸層安全性）在傳輸過程中受到保護(hù)。請(qǐng)參閱NCSC 關(guān)于推薦配置文件的指導(dǎo)，以安全地配置 TLS。使用過時(shí)的 TLS 協(xié)議或弱密碼套件的 API 會(huì)使傳輸中的數(shù)據(jù)暴露給攻擊者，從而可能被攔截和解密。這使得 API 容易受到中間人 (AiTM) 攻擊，從而可能泄露憑據(jù)和個(gè)人數(shù)據(jù)等敏感信息。

如果 API 是為小型社區(qū)托管的（或者是私有 API），請(qǐng)考慮使用相互認(rèn)證協(xié)議，例如Mutual TLS (mTLS)。這將提供雙向身份驗(yàn)證，確保客戶端和服務(wù)器在建立安全連接之前驗(yàn)證彼此的身份。如果您確實(shí)使用 mTLS，則可能需要為 mTLS 的客戶端身份驗(yàn)證部分 構(gòu)建私有 PKI 。

4. 輸入驗(yàn)證

輸入驗(yàn)證是在處理 API 收到的數(shù)據(jù)之前對(duì)其進(jìn)行檢查和驗(yàn)證的過程。此驗(yàn)證可確保輸入符合指定的標(biāo)準(zhǔn)（例如數(shù)據(jù)類型、格式、長度和范圍），并且不含潛在的惡意或意外內(nèi)容。有關(guān)更多信息，請(qǐng)參閱NCSC 安全設(shè)計(jì)原則中的“使入侵變得困難”部分。

有效的輸入驗(yàn)證對(duì)于防止各種安全漏洞至關(guān)重要，包括注入攻擊、數(shù)據(jù)篡改和拒絕服務(wù) (DoS) 攻擊，這些攻擊可能危及 API 資源的機(jī)密性、完整性和可用性。 

您應(yīng)該盡早驗(yàn)證輸入，最好是在從外部源接收數(shù)據(jù)時(shí)進(jìn)行驗(yàn)證，并確保在每個(gè)系統(tǒng)層都進(jìn)行驗(yàn)證。層與層之間無意的不一致是造成漏洞的一個(gè)眾所周知的原因。在用戶界面層，它有助于盡早發(fā)現(xiàn)基本錯(cuò)誤。應(yīng)用程序邏輯層強(qiáng)制執(zhí)行業(yè)務(wù)規(guī)則，確保只有有效數(shù)據(jù)才能繼續(xù)，而數(shù)據(jù)訪問層則防止注入攻擊并強(qiáng)制執(zhí)行數(shù)據(jù)庫約束。在所有層上進(jìn)行一致的驗(yàn)證可降低風(fēng)險(xiǎn)并創(chuàng)建更安全的縱深防御架構(gòu)。  

如果使用 API 網(wǎng)關(guān)，它應(yīng)該執(zhí)行初始驗(yàn)證，但不應(yīng)是唯一的驗(yàn)證點(diǎn)。實(shí)施多層方法，其中網(wǎng)關(guān)處理基本檢查，而后端服務(wù)執(zhí)行詳細(xì)的、特定于上下文的驗(yàn)證。為了簡化此過程并確保一致性，請(qǐng)考慮實(shí)施中央輸入驗(yàn)證庫或流程，這樣您就無需為每個(gè)功能重新實(shí)現(xiàn)驗(yàn)證邏輯。

句法和語義驗(yàn)證

輸入驗(yàn)證應(yīng)在句法和語義層面進(jìn)行：

• 語法驗(yàn)證可確保輸入數(shù)據(jù)的語法和結(jié)構(gòu)正確，通常側(cè)重于預(yù)定義的模式、格式和約束。驗(yàn)證檢查輸入是否符合預(yù)期的標(biāo)準(zhǔn)和模式，例如電子郵件地址、電話號(hào)碼、日期或貨幣符號(hào)的正確格式。
• 語義驗(yàn)證驗(yàn)證相關(guān)業(yè)務(wù)環(huán)境中數(shù)據(jù)的正確性（例如確認(rèn)開始日期早于結(jié)束日期，或在預(yù)期范圍內(nèi)）。

通過強(qiáng)制執(zhí)行語法和語義驗(yàn)證，開發(fā)人員可以拒絕任何不符合指定語法規(guī)則且在預(yù)期上下文中準(zhǔn)確的輸入，從而降低處理錯(cuò)誤、數(shù)據(jù)損壞、安全漏洞的風(fēng)險(xiǎn)并提高數(shù)據(jù)準(zhǔn)確性。

語法驗(yàn)證的良好實(shí)踐

JSON 解析器

嚴(yán)格的 JSON 解析器可確保數(shù)據(jù)在語法上正確，驗(yàn)證其是否符合正確的 JSON 格式。如果輸入數(shù)據(jù)包含結(jié)構(gòu)錯(cuò)誤（例如括號(hào)不正確或逗號(hào)放錯(cuò)位置），解析器將引發(fā)錯(cuò)誤或異常。

集中驗(yàn)證庫

使用經(jīng)過充分測(cè)試的輸入驗(yàn)證庫或框架。這些庫通常提供類型檢查、范圍驗(yàn)證和清理等功能，減少對(duì)復(fù)雜且難以維護(hù)的正則表達(dá)式模式的依賴。

允許列表

允許列表驗(yàn)證明確定義授權(quán)輸入并確保僅接受允許的值。例如，對(duì)于來自固定選項(xiàng)（如下拉列表）的結(jié)構(gòu)化數(shù)據(jù)，應(yīng)采用數(shù)據(jù)格式的精確匹配。

架構(gòu)驗(yàn)證

JSON 模式可用于定義通過 API 交換的數(shù)據(jù)結(jié)構(gòu)，并根據(jù)這些模式驗(yàn)證傳入的有效負(fù)載。還應(yīng)使用模式驗(yàn)證來確保攻擊者不會(huì)發(fā)送意料之外的額外子句（鍵值對(duì)）。 

數(shù)據(jù)類型驗(yàn)證器

許多編程語言都提供內(nèi)置的類型檢查機(jī)制。例如，在 Java 或 TypeScript 等靜態(tài)類型語言中，編譯器可以強(qiáng)制確保數(shù)據(jù)類型的正確性。在 Python 或 JavaScript 等動(dòng)態(tài)類型語言中，可以使用庫或自定義函數(shù)來執(zhí)行類型檢查。

最小值和最大值范圍

確保數(shù)值參數(shù)和日期在指定的最小和最大范圍內(nèi)，并且字符串符合定義的長度標(biāo)準(zhǔn)。

轉(zhuǎn)義和編碼

對(duì)用戶輸入進(jìn)行轉(zhuǎn)義和編碼是一項(xiàng)重要的安全措施，通過將用戶輸入轉(zhuǎn)換為在應(yīng)用程序中不具有任何功能意義的格式，確保正確處理特殊字符以防止漏洞（例如 SQL 注入或跨站點(diǎn)腳本）。

5. 緩解 DoS 攻擊

針對(duì) API 的常見攻擊是耗盡 API 可用的資源，這可能導(dǎo)致 DoS 或增加托管 API 的成本?？紤]限制或限制 API 的使用速率。“限制”是指對(duì) API 的調(diào)用頻率/速度施加配額。這通常以每秒可以發(fā)出的請(qǐng)求數(shù)來衡量，并且應(yīng)該允許合法消費(fèi)者使用量激增。當(dāng) API 缺乏速率限制和限制時(shí)，它們很容易受到過多請(qǐng)求的影響，從而導(dǎo)致服務(wù)器不堪重負(fù)，導(dǎo)致拒絕服務(wù) (DoS) 攻擊或資源耗盡。

允許使用量激增是一種很好的做法，因?yàn)橛袝r(shí) API 的使用者可能需要發(fā)出更多合法請(qǐng)求。您還應(yīng)該記錄使用者嘗試訪問 API 的次數(shù)，以便分析是否存在合法的流量激增，或者您是否受到了潛在的 DoS 攻擊。有關(guān)如何理解和緩解 DoS 攻擊的更多信息，請(qǐng)參閱 NCSC 的拒絕服務(wù) (DoS) 指南。  

6. 日志記錄和監(jiān)控

日志記錄和監(jiān)控雖然密切相關(guān)且經(jīng)常一起使用，但用途不同。日志記錄是回顧性的，提供全面的審計(jì)跟蹤，可用于故障排除、取證分析、合規(guī)性審計(jì)和事件響應(yīng)。它側(cè)重于存儲(chǔ)信息以供日后審查和分析。另一方面，監(jiān)控涉及對(duì)系統(tǒng)行為、性能指標(biāo)和安全指標(biāo)的持續(xù)、實(shí)時(shí)觀察和分析。

允許使用量激增是一種很好的做法，因?yàn)橛袝r(shí) API 的使用者可能需要發(fā)出更多合法請(qǐng)求。您還應(yīng)該記錄使用者嘗試訪問 API 的次數(shù)，以便分析是否存在合法的流量激增，或者您是否受到了潛在的 DoS 攻擊。有關(guān)如何理解和緩解 DoS 攻擊的更多信息，請(qǐng)參閱 NCSC 的為了安全目的需要收集哪些數(shù)據(jù)以及何時(shí)收集。  

日志記錄

日志記錄是對(duì)系統(tǒng)內(nèi)事件、操作和交易的系統(tǒng)記錄。這些日志按時(shí)間順序記錄用戶活動(dòng)、系統(tǒng)更改和數(shù)據(jù)訪問，從而全面了解 API 的運(yùn)營狀況。在 API 安全中，日志記錄是保持對(duì) API 生態(tài)系統(tǒng)內(nèi)操作和交互的可見性的重要組成部分。

記錄安全事件

確保日志捕獲重要的安全相關(guān)事件，包括身份驗(yàn)證和授權(quán)活動(dòng)，例如登錄嘗試、權(quán)限更改、失敗的請(qǐng)求、錯(cuò)誤和敏感操作，例如密碼更改、帳戶修改和權(quán)限提升。

實(shí)施集中日志記錄

如果可能的話，實(shí)施一個(gè)集中式日志系統(tǒng)來匯總和分析日志，確保來自多個(gè)服務(wù)和微服務(wù)的數(shù)據(jù)集中在一個(gè)地方。

記錄訪問、錯(cuò)誤和事務(wù)日志

跟蹤訪問日志、錯(cuò)誤日志和交易數(shù)據(jù)以監(jiān)控 API 活動(dòng)并確保安全。記錄每個(gè) API 調(diào)用的詳細(xì)信息，包括時(shí)間戳、源 IP、用戶身份和訪問的端點(diǎn)。這有助于識(shí)別未經(jīng)授權(quán)的訪問、跟蹤用戶交互并檢測(cè)可能表明潛在安全威脅或欺詐活動(dòng)的異常交易模式。

保護(hù)日志中的敏感數(shù)據(jù)

絕不應(yīng)記錄密碼、API 密鑰、訪問令牌和個(gè)人身份信息 (PII) 等敏感數(shù)據(jù)。相反，應(yīng)使用數(shù)據(jù)編輯或屏蔽來保護(hù)機(jī)密信息，并確保日志在靜止和傳輸過程中均經(jīng)過加密。

監(jiān)控

監(jiān)控系統(tǒng)跟蹤關(guān)鍵指標(biāo)，例如 API 響應(yīng)時(shí)間、正常運(yùn)行時(shí)間、資源利用率和安全事件。它們檢測(cè)異常、生成警報(bào)，并在超出預(yù)定義閾值或發(fā)現(xiàn)可疑活動(dòng)時(shí)通知管理員或安全團(tuán)隊(duì)。

監(jiān)控是一種主動(dòng)預(yù)防性措施，旨在發(fā)現(xiàn)并解決發(fā)生的問題，確保 API 基礎(chǔ)設(shè)施持續(xù)健康安全。監(jiān)控在維護(hù) API 的完整性和可用性以及檢測(cè)和緩解安全威脅方面發(fā)揮著至關(guān)重要的作用。

啟用實(shí)時(shí)監(jiān)控和警報(bào)

使用 SIEM（安全信息和事件管理）工具來監(jiān)控日志、檢測(cè)威脅并啟用異常檢測(cè)。設(shè)置可疑活動(dòng)警報(bào)，例如多次登錄嘗試失?。ū硎緷撛诘谋┝簦┗?API 流量激增（可能表示 DoS 攻擊）、日志突然停止（可能表示篡改或正在進(jìn)行攻擊）或異常/大量數(shù)據(jù)傳輸（可能表示數(shù)據(jù)泄露）。確保持續(xù)的日志完整性和監(jiān)控?cái)?shù)據(jù)移動(dòng)有助于在安全威脅升級(jí)之前檢測(cè)和緩解它們。

端點(diǎn)性能跟蹤

實(shí)施端點(diǎn)性能跟蹤，重點(diǎn)監(jiān)控 API 端點(diǎn)的可用性和性能。它跟蹤響應(yīng)時(shí)間、錯(cuò)誤率和可用性，以確保它們按預(yù)期運(yùn)行，并檢測(cè)可能影響 API 可用性或可靠性的任何問題。

7. 限制暴露面

不應(yīng)過度暴露 API 端點(diǎn)或允許已知的惡意 IP 地址連接到API。限制暴露面，使攻擊者甚至無法訪問 API 的某些敏感部分，這將降低您的應(yīng)用程序受到攻擊的可能性。 

限制接觸端點(diǎn)

API 端點(diǎn)是客戶端用來連接到 API 的 URL。應(yīng)該有效管理向客戶公開的 API 端點(diǎn)。除非訪問權(quán)限嚴(yán)格限制在受信任的網(wǎng)絡(luò)（或攻擊者無法控制的設(shè)備）內(nèi)，否則攻擊者可能會(huì)擁有一定程度的訪問權(quán)限（可能通過反編譯應(yīng)用等方法來提取 API 端點(diǎn)和密鑰）。

刪除未使用的端點(diǎn)

當(dāng) API 更新時(shí)，端點(diǎn)有時(shí)會(huì)暴露在外，尤其是在 API 正在（或已經(jīng)）停用的情況下。在這種情況下，這可能意味著所有監(jiān)控和安全功能都將處于非活動(dòng)狀態(tài)，尤其是在不再使用的情況下。這也可能意味著可能存在漏洞的 API 端點(diǎn)暴露在外且可訪問。當(dāng) API 端點(diǎn)被棄用時(shí)，IT 團(tuán)隊(duì)需要確保端點(diǎn)不再可訪問并且訪問被阻止。第 1 節(jié)中提到的資產(chǎn)登記冊(cè)將對(duì)此有所幫助。  

限制對(duì)特權(quán)端點(diǎn)的訪問

被視為敏感的端點(diǎn)（例如用于管理 API 的端點(diǎn)）也應(yīng)具有受限的網(wǎng)絡(luò)訪問權(quán)限，并且不應(yīng)公開訪問。這使得攻擊者或惡意用戶更難訪問敏感 API 并試圖利用它。您應(yīng)該主動(dòng)掃描您的環(huán)境，以確保您知道哪些內(nèi)容是公開的。這將使您能夠主動(dòng)發(fā)現(xiàn)任何過度暴露的舊版、開發(fā)或管理 API。

阻止已知惡意 IP 地址 

阻止已知的惡意 IP 地址以及不應(yīng)連接到您的 API 的 IP 地址類別的連接。以這種方式阻止 IP 地址通常是許多 Web 應(yīng)用程序防火墻 (WAF) 中提供的功能。如果可能，您應(yīng)該嘗試使用托管規(guī)則集來阻止 IP 地址，因?yàn)檫@將大大減少您的管理開銷。您需要調(diào)整規(guī)則集，因此您可能需要在執(zhí)行規(guī)則之前監(jiān)視規(guī)則，以防您最終意外阻止了合法流量。

封閉社區(qū)的 API 暴露

如果您托管的是私有 API 或在封閉社區(qū)（例如 CNI 部門或政府部門組）中使用的 API，請(qǐng)考慮進(jìn)一步限制 API 的暴露。這可以采用 mTLS、IP 地址允許列表或使用 VPN 的形式。您將使用哪種方法來減少暴露將取決于封閉社區(qū)的規(guī)模、威脅和要求。 

API 響應(yīng)

如果 API 返回過多或不必要的數(shù)據(jù)，則可能會(huì)泄露敏感信息，例如內(nèi)部標(biāo)識(shí)符、用戶個(gè)人標(biāo)識(shí)符 (PII) 或調(diào)試詳細(xì)信息。此類暴露可能有助于攻擊者收集針對(duì)性攻擊的情報(bào)，或?qū)е聼o意中泄露用戶隱私。

API 網(wǎng)關(guān)安全

大規(guī)模部署 API 時(shí)，請(qǐng)使用 API 網(wǎng)關(guān)，因?yàn)檫@將提供一致的安全方法。如果您在公共云中托管 API，那么您應(yīng)該考慮使用云原生基礎(chǔ)設(shè)施，而不是將本地解決方案遷移到云中。 

API 網(wǎng)關(guān)充當(dāng)客戶端和后端服務(wù)之間的中介，為管理和保護(hù) API 流量提供集中入口點(diǎn)。API 網(wǎng)關(guān)的集中特性簡化了大規(guī)模構(gòu)建 API 時(shí)安全功能的實(shí)現(xiàn)。API 網(wǎng)關(guān)可以提供一種方法來提供安全功能的一致實(shí)現(xiàn)，因?yàn)檫@些功能是在網(wǎng)關(guān)中提供的，而不是后端應(yīng)用程序代碼中提供的。

您可以在 API 網(wǎng)關(guān)中找到的一些安全功能包括：

• 架構(gòu)驗(yàn)證（如第 4 節(jié)所述）
• 客戶端的身份驗(yàn)證和授權(quán)；API 網(wǎng)關(guān)通常支持 OpenID Connect 和 OAuth 2.0 等框架
• 提供一個(gè)用于監(jiān)控和記錄 API 端點(diǎn)的中心點(diǎn)
• 集成到 WAF 和 IDS 等工具中，可以用作縱深防御并限制 API 的暴露