在采用AI的過程中，最令人擔(dān)憂的問題之一是數(shù)據(jù)泄露。想象一下這樣的場(chǎng)景：一名員工登錄到他們常用的AI聊天機(jī)器人中，粘貼了敏感的公司機(jī)密數(shù)據(jù)，并要求對(duì)其進(jìn)行總結(jié)。就這樣，機(jī)密信息被輸入到了不受你控制的第三方模型中。

即使有數(shù)據(jù)防丟失(DLP)策略，預(yù)防AI數(shù)據(jù)泄露也頗具挑戰(zhàn)。如果AI系統(tǒng)是基于云的，且員工可以在外部訪問它，那么公司可能永遠(yuǎn)不會(huì)知道自己的數(shù)據(jù)何時(shí)遭到了泄露。

此外，大多數(shù)AI供應(yīng)商不僅提供網(wǎng)頁(yè)界面，還通過API提供程序化訪問，然而，API也帶來(lái)了一個(gè)重大的安全盲點(diǎn)。如果AI供應(yīng)商允許遠(yuǎn)程API訪問，你如何驗(yàn)證是誰(shuí)在使用它?如果攻擊者獲得了API令牌的訪問權(quán)限，他們可以在不被發(fā)現(xiàn)的情況下提取或操縱數(shù)據(jù)。

AI安全檢查清單：在供應(yīng)商中尋找什么

如果你在評(píng)估AI提供商，安全必須是首要考慮因素，尤其是在處理敏感業(yè)務(wù)數(shù)據(jù)時(shí)。以下是選擇AI供應(yīng)商時(shí)必須具備的安全功能：

1. 認(rèn)證和授權(quán)標(biāo)準(zhǔn)

API訪問絕不應(yīng)通過用戶名和密碼授予。相反，應(yīng)尋找基于令牌的認(rèn)證：

? 供應(yīng)商必須支持OAuth 2.0以進(jìn)行安全令牌生成

? 令牌應(yīng)繼承或具有可分配的權(quán)限，以確保最小權(quán)限訪問

? 禁止令牌共享。每個(gè)系統(tǒng)或用戶都應(yīng)有唯一的憑據(jù)

2. 令牌監(jiān)控與生命周期管理

供應(yīng)商應(yīng)提供活動(dòng)認(rèn)證令牌的集中列表，并且令牌應(yīng)包含元數(shù)據(jù)，如：

? 由誰(shuí)創(chuàng)建

? 創(chuàng)建時(shí)間、最后修改時(shí)間和最后使用時(shí)間

? 分配的權(quán)限

? 是否仍然有效或已過期

3. 全面的API日志記錄和審計(jì)軌跡

AI供應(yīng)商必須提供API訪問的審計(jì)日志，并且這些日志應(yīng)可通過API進(jìn)行實(shí)時(shí)監(jiān)控。每個(gè)日志條目至少應(yīng)包括：

? 訪問的日期和時(shí)間

? 源IP地址

? 用于訪問的令牌

? 執(zhí)行的操作(例如，“創(chuàng)建新令牌”，“檢索數(shù)據(jù)”)

? 成功或失敗狀態(tài)

高級(jí)日志記錄應(yīng)包括完整的API端點(diǎn)、HTTP方法和HTTP響應(yīng)代碼，以提供詳細(xì)見解。

4. 透明的文檔

AI供應(yīng)商應(yīng)以開放格式(例如，OpenAPI或Swagger)提供完整的API文檔。如果沒有適當(dāng)?shù)奈臋n，組織將無(wú)法了解其AI交互的日志記錄和安全性。

隱藏的API安全危機(jī)

在研究了兩年多的API安全后，我仍然對(duì)AI供應(yīng)商中缺乏日志記錄、監(jiān)控和安全功能感到震驚。沒有足夠日志記錄的API創(chuàng)建了一個(gè)無(wú)形的攻擊面，使得未經(jīng)授權(quán)的訪問可以在不被發(fā)現(xiàn)的情況下發(fā)生。

我們已經(jīng)聽說(shuō)過API令牌在GitHub存儲(chǔ)庫(kù)中被泄露或在暗網(wǎng)論壇上被出售的恐怖故事。一旦攻擊者獲得了有效的API令牌，他們就可以無(wú)限期地利用它，直到有人發(fā)現(xiàn)為止。

AI已經(jīng)到來(lái)，但安全不能再被忽視。在信任任何AI供應(yīng)商處理敏感數(shù)據(jù)之前，組織必須要求透明的API安全、嚴(yán)格的監(jiān)控和強(qiáng)大的認(rèn)證控制。

如果AI供應(yīng)商缺乏基本的安全控制，他們就會(huì)帶來(lái)風(fēng)險(xiǎn)。AI供應(yīng)商應(yīng)為安全負(fù)責(zé)。如果AI供應(yīng)商無(wú)法回答是誰(shuí)在使用他們的API、上次訪問時(shí)間以及如何使用它們，那么他們就不值得你的業(yè)務(wù)。