容器吏口，微服務(wù)和API奄容，它們共同構(gòu)成了云計算的三位一體。作為云計算的一部分产徊，它們都必須保證安全昂勒。如果API存在安全風(fēng)險，那么另外兩個也會面臨風(fēng)險舟铜，并且可能會危及企業(yè)的安全戈盈。
API是應(yīng)用程序的微服務(wù)和容器的粘合劑。 它們?yōu)槲⒎?wù)器提供相互通信的通道谆刨，為數(shù)據(jù)提供訪問塘娶，它們是互聯(lián)網(wǎng)的傳感器。
云計算倡導(dǎo)者面臨的挑戰(zhàn)是痊夭，API安全風(fēng)險正在隨著技術(shù)的普及而上升刁岸。 為了應(yīng)對未經(jīng)授權(quán)的更改數(shù)據(jù)，數(shù)據(jù)泄漏和干擾合法活動所造成的各種威脅她我，需要采取多方面的方法虹曙。 該方法包括沙盒，網(wǎng)絡(luò)連接控制和加密番舆。
API管理還可以幫助最小化與物流有關(guān)的安全風(fēng)險根吁，如主要汽車制造商面臨的安全風(fēng)險。 其全電動車輛的服務(wù)和旅行歷史可以通過僅需要車輛識別號碼的API呼叫容易地被黑客入侵合蔽，這可以通過任何擋風(fēng)玻璃容易地觀看击敌。 我們需要做的更好。 其他API安全風(fēng)險包括同時控制多個版本拴事，特別是當(dāng)外部客戶使用該API時沃斤，以及確定第三方API是否符合安全性，效率和性能標準的挑戰(zhàn)刃宵。
本手冊探討潛在的API安全風(fēng)險衡瓶，并提出了維護一個安全、可管理的環(huán)境的一系列最佳實踐牲证。
為什么現(xiàn)在是實施安全API最佳實踐的時候了
應(yīng)用程序（即使是第三方應(yīng)用程序）越來越依賴網(wǎng)絡(luò)連接的API來在應(yīng)用程序元素內(nèi)部和之間傳遞工作哮针。 每個API都代表了一個關(guān)鍵特性，潛在的安全和合規(guī)性問題。 雖然在安全API方面有很多新的開發(fā)工具十厢，但API安全性最佳實踐的秘訣就是流程而不是工具等太。 您的第一步應(yīng)該是確定API暴露的主要安全風(fēng)險，以特定的順序應(yīng)用補救措施蛮放，以避免在過度使用他人并將安全性集成到應(yīng)用程序生命周期管理中時丟失一些點缩抡，以防止您的預(yù)防措施泄漏。
自編程初期以來包颁，API的概念發(fā)生了巨大變化瞻想。 今天，API是與應(yīng)用程序功能或數(shù)據(jù)庫信息的網(wǎng)絡(luò)連接娩嚼，這個新角色意味著API需要越來越嚴格的安全性和合規(guī)性保護來保護下面的信息蘑险。 大多數(shù)企業(yè)都知道這一點，并轉(zhuǎn)而保護他們的API岳悟，但很少有人通過實施安全的API最佳實踐來設(shè)法杜絕所有的風(fēng)險漠其。
解決API安全風(fēng)險
我們正處于API使用的新時代的開始，現(xiàn)在需要解決這些風(fēng)險竿音。 現(xiàn)代API引入了三個明顯的安全隱患：未經(jīng)授權(quán)的信息更改和屎，信息泄漏和對合法活動的干擾。 所有這三個都是有問題的春瞬，并且都來自相同的來源柴信，因為聯(lián)網(wǎng)的API通常默認為所有網(wǎng)絡(luò)。
今天的API有一個網(wǎng)絡(luò)地址宽气，可以將其編織成工作流程随常，任何知道或猜測地址的人都可以向API發(fā)送一些內(nèi)容。 如果請求是通過API下的軟件的方式構(gòu)建的萄涯，那么API代表的函數(shù)將會運行绪氛，并且會發(fā)生一些事情。 信息可能會返回給不應(yīng)該被允許使用的人涝影，也可能被更改枣察。 即使是具有錯誤格式的“垃圾”請求也可能會浪費處理能力，為API和使用它的任何應(yīng)用程序創(chuàng)造機會燃逻。
許多用戶期望通過使用位于API和可能訪問它們的應(yīng)用程序之間的目錄或管理功能來解決安全API序目，因此僅提供間接和策略控制的訪問。 這種方法的問題是通常不會使API無法訪問伯襟，除非通過管理工具; API仍然是一個網(wǎng)絡(luò)尋址的實體猿涨，它可以通過掃描IP地址來定位。
實現(xiàn)安全API
最有效的API安全性最佳實踐從多區(qū)域網(wǎng)絡(luò)開始姆怪。 應(yīng)用程序應(yīng)在安全區(qū)域或沙箱內(nèi)運行叛赚，并僅向外界公開幾個服務(wù)地址澡绩。 不能向所有人提供的API應(yīng)該托管在此安全區(qū)域內(nèi)。 一些托管架構(gòu)俺附，包括Docker容器肥卡，自然提供安全區(qū)域，它們可以通過現(xiàn)在可用的大多數(shù)私人軟件定義的網(wǎng)絡(luò)架構(gòu)來實現(xiàn)昙读。 通過建立多區(qū)域網(wǎng)絡(luò)召调，安全的API問題將大大降低膨桥。
實現(xiàn)安全API最佳實踐的下一步是網(wǎng)絡(luò)連接控制蛮浑。 不是通過管理員調(diào)解對API的訪問，而是通過網(wǎng)絡(luò)策略管理來控制API的地址只嚣。 這種方法測試消息的源IP地址沮稚，例如，只將消息從適當(dāng)?shù)挠脩魝鬟f到API册舞。 仍然有一些繞過這種保護的方法蕴掏，但它提供了最好的保證，API將不被未經(jīng)授權(quán)的個人訪問; 它還提供防止拒絕服務(wù)攻擊您的API的保護调鲸。 對建立安全區(qū)域的網(wǎng)絡(luò)應(yīng)用網(wǎng)絡(luò)連接控制是最簡單的盛杰，因為可以容易地識別區(qū)域內(nèi)流量。 因此藐石，只有暴露在區(qū)域外使用的API才能得到保護即供。
網(wǎng)絡(luò)連接控制可以清除入侵者，但與公司內(nèi)部廣泛使用的應(yīng)用程序相關(guān)的API可能仍然可以由不需要的人員或API代表的信息的權(quán)限進行訪問于微。 API管理可以“認證”用戶逗嫡，在某些實現(xiàn)中，它也可以實際重定向流量株依，因此API消息只能來自API管理器驱证，而不是直接從用戶的信息來源。 添加到網(wǎng)絡(luò)連接控制恋腕，這大大有助于實現(xiàn)安全的API最佳實踐抹锄。
最后一步是加密。 如果對API的消息必須加密荠藤，那么直接訪問API的嘗試將不會通過加密測試祈远，并將被丟棄。 在大多數(shù)情況下商源，最好是由API的用戶直接生成加密车份，而不是API管理器。 但是請確保足夠的消息清楚地允許API管理員應(yīng)用訪問策略牡彻。 通常践宴，IP報頭是足夠的子檀，但是在某些情況下学辱，也可以使用較高層報頭進行認證。 如果API管理員需要的信息被加密严就，那么管理者將不得不解密然后再次加密，從而產(chǎn)生延遲器罐。
實施所有這些步驟可以提供堅實的安全的API最佳實踐梢为，但即使將所有這些措施付諸實踐的企業(yè)仍然可以發(fā)現(xiàn)其API是暴露的。 最大的問題發(fā)生在應(yīng)用程序更改時轰坊，特別是當(dāng)應(yīng)用程序共享通過API訪問的組件時铸董。 組件共享是大多數(shù)開發(fā)團隊的目標，旨在降低成本并加快對業(yè)務(wù)變化的響應(yīng)肴沫。 分享API秘密意味著告訴他們粟害，這可能意味著失去控制。
如果您有代表共享應(yīng)用程序組件的API颤芬，請考慮在網(wǎng)絡(luò)計劃中為他們提供自己的區(qū)域或沙箱悲幅。 這使您可以選擇性地將連接控制和加密應(yīng)用于需要比正常使用更多開放使用，但又不完全開放使用的API站蝠。 所以在規(guī)劃API安全性時先看連接控制汰具。
安全API戰(zhàn)略的最大敵人是一心一意。 解決安全問題沒有銀彈菱魔。 以正確的順序和正確的重點留荔，應(yīng)用所有的API安全最佳實踐，才會產(chǎn)生最好的結(jié)果豌习。
====================================
避免外部和內(nèi)部API性能問題的幾點技巧
在說服用戶整合到您的系統(tǒng)中后存谎，您肯定不希望讓他們遭遇API性能問題。 確保用戶API性能不成問題肥隆。
我們需要承認既荚，軟件不完美。 無論產(chǎn)品的可靠性如何栋艳，或者測試得多么完全恰聘，它仍然會時不時得發(fā)生故障或崩潰。 缺陷的存在是一個事實吸占。
幸運的是晴叨，作為工程師，我們有預(yù)測和補償這些問題的工具矾屯。 分析兼蕊，監(jiān)控，日志聚合件蚕，警報孙技，負載平衡产禾，單元測試，緩存...牵啦。
當(dāng)涉及到創(chuàng)建和使用API時亚情，這些策略變得非常重要，因為API不具有作為獨立的環(huán)境哈雏。 由于API是使用它們的每個應(yīng)用程序中的潛在故障點楞件，因此不僅要監(jiān)視您創(chuàng)建的組件的API性能，還要監(jiān)視您使用的組件的API性能裳瘪。
API性能監(jiān)控
顯然土浸，為了確保產(chǎn)品的快速和可靠，重要的是先一步發(fā)現(xiàn)潛在問題盹愚，但我們?nèi)绾潍@取API性能呢栅迄？
一般來說站故，獲取API性能與獲取任何其他類型的應(yīng)用程序性能沒有什么不同皆怕。 主要關(guān)注的是請求延遲。如果API成為消費者應(yīng)用程序的瓶頸西篓，則意味著會丟失更多的性能愈腾。 對于內(nèi)部和外部API，請求延遲是一個相對簡單的統(tǒng)計岂津，可以通過很多專業(yè)和商業(yè)的方法來獲取到虱黄。
外部API性能最佳實踐
內(nèi)部API性能監(jiān)測是一個非常簡單的過程，處理外部API可能會更困難一點; 特別是當(dāng)它們影響到關(guān)鍵任務(wù)吮成，并且可能缺少可靠性橱乱。
第三方API實際上是黑盒子; 請求進來，響應(yīng)出來粱甫，幾乎沒有透明度泳叠。 幸運的是，上述相同的平臺和工具通常也可以用于監(jiān)視對外部API的請求的延遲茶宵。
監(jiān)控的具體實現(xiàn)將因平臺而異危纫，但要特別注意隱含地跟蹤應(yīng)用程序中的API請求，因為可能需要盡早盡快地識別問題乌庶。
如果API性能很差种蝶，并且在改善API的可用性上能做的很有限，那么將API請求從面向客戶端的代碼中移除瞒大，可以幫助緩解問題螃征。更普遍的做法是，采用異步處理和數(shù)據(jù)管理透敌。
了解每個API請求的平均延遲對于確定數(shù)據(jù)的緩存時長盯滚，哪些數(shù)據(jù)應(yīng)該長期存儲锅棕，甚至哪些關(guān)鍵請求應(yīng)該及時響應(yīng)都非常有幫助。
最終淌山，API性能監(jiān)控與任何其他類型的應(yīng)用程序監(jiān)控沒有什么不同裸燎。 使用API的區(qū)別是應(yīng)用程序如何應(yīng)用它們。 在任何應(yīng)用程序中都有很多依賴的部分泼疑，而這種依賴意味著要注意API在應(yīng)用程序中是否能有效得運行德绿。
通過優(yōu)化數(shù)據(jù)庫查詢和緩存耗時操作等一系列措施，可以大大提高API的整體運行狀況退渗。
英文原文鏈接：
http://searchcloudapplications.techtarget.com/ehandbook/Sound-application-development-rests-with-secure-APIs-in-the-cloud
