API網(wǎng)關(guān)如何發(fā)展：更輕、更智能、云原生
當(dāng)銷售代表調(diào)用系統(tǒng)檢索訂單信息時(shí)，系統(tǒng)會評估他們是否具有必要的權(quán)限。如果我們使用 ABAC，我們可以根據(jù)這些特定屬性定義規(guī)則來接受或拒絕請求。例如，可能只有admin_level3 或以上的用戶才被允許查看訂單詳細(xì)信息。此外，與該字段相關(guān)的規(guī)則user_id可以確保銷售代表只能查看與他們分配的客戶相關(guān)的訂單。
此類屬性也可以自動(dòng)分配，以遵循組織的行為。例如，假設(shè)銷售代表創(chuàng)建了一個(gè)新用戶。系統(tǒng)會使用與created_by銷售代表相匹配的字段來更新此新客戶資料，從而將此客戶綁定到特定銷售代表的帳戶，并防止未經(jīng)授權(quán)的用戶訪問。
user {
user_id: 00918;
created_by: 123;
orderPlaced: yes;
}更進(jìn)一步，我們可以將銷售代表的用戶 ID 添加到每個(gè)訂單號前面，如下所示：
orderID {
orderNumber: $incrementOrder;
prepend: created_by;
}這將為該用戶下達(dá)的與銷售代表關(guān)聯(lián)的訂單生成一個(gè)類似于“123-00011”的訂單號。從這里，我們可以確保銷售代表只能訪問帶有此前綴值的訂單，而不能查看與其他銷售代表關(guān)聯(lián)的訂單。
這消除了一個(gè)客戶訪問另一個(gè)客戶的訂單的風(fēng)險(xiǎn)，而 RBAC 可能無法很好地處理這種風(fēng)險(xiǎn)。它還提供了一種動(dòng)態(tài)調(diào)整特定權(quán)限的方法，并避免了角色爆炸的可能性。
現(xiàn)在我們已經(jīng)了解了 ABAC 是什么樣子的，讓我們看看在為 API 設(shè)計(jì) ABAC 時(shí)應(yīng)該考慮哪些設(shè)計(jì)因素。
由于我們所有的控制權(quán)都掌握在屬性本身，而不是與這些屬性交互的用戶手中，因此 API 提供商應(yīng)該認(rèn)真考慮應(yīng)該使用哪些具體屬性。與角色不同，角色由組織結(jié)構(gòu)和與系統(tǒng)交互的人員的實(shí)際情況明確設(shè)定，而屬性則更加不透明。它們很大程度上取決于提供商的發(fā)現(xiàn)。
安全數(shù)據(jù)
尋求基本訪問控制的 API（尤其是處理少量數(shù)據(jù)的 API）不應(yīng)僅僅因?yàn)榇嬖诠ぞ呔蛯?ABAC 視為構(gòu)建高度詳細(xì)系統(tǒng)的機(jī)會。對于錘子來說，所有東西看起來都像釘子 — 提供商應(yīng)考慮保護(hù)其服務(wù)所需的最少屬性，并從這種理解出發(fā)開始設(shè)置其安全態(tài)勢。
授權(quán)流程應(yīng)允許客戶端檢索帶有屬性的訪問令牌并將其發(fā)送到 API。例如，當(dāng)用戶發(fā)送請求時(shí)，客戶端會將用戶重定向到身份系統(tǒng)進(jìn)行身份驗(yàn)證，并發(fā)出包含屬性的令牌。然后，該令牌將發(fā)送到 API。然后，API 會驗(yàn)證來自身份系統(tǒng)的令牌，信任它們并使用它們的屬性。下圖描述了這種情況。
使用令牌進(jìn)行基于屬性的訪問控制的授權(quán)流程。
同樣，應(yīng)該有一個(gè)通過屬性更新和超時(shí)來撤銷訪問權(quán)限的計(jì)劃。屬性不是永久的，就像授權(quán)流程一樣，應(yīng)該可以隨著需求和訪問級別的變化而被撤銷或更新。因此，重要的是不僅要考慮在給定屬性的情況下，流程現(xiàn)在是什么樣子，還要考慮它們可能是什么樣子，以及提供商如何控制這些屬性來控制這樣的環(huán)境。
特定的架構(gòu)風(fēng)格，例如 GraphQL
最終，屬性將成為控制 ABAC 方法的核心系統(tǒng)，因此，應(yīng)以與密鑰或令牌相同的安全姿態(tài)和考慮來對待屬性 – 這包括充足的靜態(tài)和傳輸加密、跟蹤屬性、采用合理的棄用模式等。實(shí)現(xiàn)這樣的架構(gòu)需要采用靈活而強(qiáng)大的集成解決方案。
值得慶幸的是，OAuth 2.0等解決方案是強(qiáng)大的訪問控制解決方案，允許大規(guī)模高水平的控制和效率，使得 ABAC 的采用相對容易上手。
ABAC是一種比 RBAC 更強(qiáng)大的方法，在可擴(kuò)展性和可伸縮性方面具有顯著優(yōu)勢。然而，采用 ABAC 確實(shí)需要更大的分離度和更復(fù)雜的流程。對于某些 API，這可能過于復(fù)雜，帶來管理問題，而且具有諷刺意味的是，由于管理復(fù)雜且需要跟蹤更大的系統(tǒng)，它本身也存在擴(kuò)展問題。
然而，通過充分的規(guī)劃，并結(jié)合跟蹤、更新、撤銷和棄用計(jì)劃，ABAC 確實(shí)可以用來構(gòu)建一個(gè)非常安全的系統(tǒng)。
原文地址：https://nordicapis.com/how-to-implement-attribute-based-access-control-for-apis/
