六大權(quán)益！華為8月服務(wù)日開(kāi)啟：手機(jī)免費(fèi)貼膜、維修免人工費(fèi)
8月5日消息，一年一度的華為開(kāi)發(fā)者大會(huì)2023（Together）日前在松山湖拉開(kāi)帷幕，與此同時(shí)，華為8月服務(wù)日也式開(kāi)啟，到店可享六大專屬權(quán)益。華為用戶可在華為商城Ap
與當(dāng)前正在使用的任何其他技術(shù)或方法一樣，微服務(wù)也有其自己的一套缺陷和問(wèn)題。盡管如此，微服務(wù)架構(gòu)的采用率不斷增加，預(yù)計(jì)到2028年將達(dá)到1718.2億美元。
然而，盡管團(tuán)隊(duì)使用微服務(wù)，但確保這些微服務(wù)的安全性仍然被視為事后事項(xiàng)。 這可能導(dǎo)致應(yīng)用程序中的許多安全問(wèn)題，甚至可能使用戶數(shù)據(jù)面臨風(fēng)險(xiǎn)，甚至導(dǎo)致應(yīng)用程序停機(jī)。因此，讓我們看看在2024年保護(hù)微服務(wù)的前10種方法！
在深入研究保護(hù)微服務(wù)之前，了解可能使您基于微服務(wù)的應(yīng)用程序面臨風(fēng)險(xiǎn)的威脅是很重要的。
攻擊者獲取對(duì)基于微服務(wù)的應(yīng)用程序的訪問(wèn)權(quán)限的主要原因是身份驗(yàn)證和訪問(wèn)策略的配置錯(cuò)誤。這些策略和機(jī)制的配置錯(cuò)誤將是災(zāi)難性的，因?yàn)樗赡鼙┞睹舾行畔ⅲ踔磷尮粽咄ㄟ^(guò)執(zhí)行遠(yuǎn)程代碼來(lái)獲得對(duì)系統(tǒng)的訪問(wèn)權(quán)限。
在微服務(wù)架構(gòu)中，API安全性的重要性是毫無(wú)爭(zhēng)議的，因?yàn)槊總€(gè)組件都與API相互連接；此外，當(dāng)OWASP提出其自己的十大最常見(jiàn)問(wèn)題清單時(shí)，您就知道這個(gè)方面有多重要。
攻擊者通常通過(guò)身份驗(yàn)證和有效載荷處理配置錯(cuò)誤來(lái)利用API端點(diǎn)，通過(guò)操縱有效載荷繞過(guò)可能已經(jīng)設(shè)置的任何驗(yàn)證。
在適當(dāng)?shù)目刂拼胧┤笔У那闆r下，沒(méi)有人免疫拒絕服務(wù)攻擊。
這是我們必須接受的現(xiàn)實(shí)，因?yàn)槿魏稳硕伎梢暂p松獲取提供DDoS服務(wù)的服務(wù)，價(jià)格低至每天$30，具體取決于攻擊的規(guī)模和持續(xù)時(shí)間。 當(dāng)您的基于微服務(wù)的應(yīng)用程序可能能夠擴(kuò)展以抵抗DDoS或DoS攻擊以保持其服務(wù)運(yùn)行時(shí)；
真正的問(wèn)題是以何種代價(jià)？ 在DDoS或DoS攻擊期間，微服務(wù)的擴(kuò)展將對(duì)成本產(chǎn)生重大影響，因?yàn)榧词故褂弥T如AWS Lambda等無(wú)服務(wù)器解決方案，計(jì)算資源也不便宜。
既然我們已經(jīng)確認(rèn)了即使微服務(wù)也會(huì)受到攻擊，并且這只是一個(gè)“何時(shí)”的問(wèn)題。
讓我們看看一些策略，我們可以實(shí)施以減少攻擊可能帶來(lái)的影響。
顧名思義，安全設(shè)計(jì)或左移安全性意味著安全性必須從設(shè)計(jì)階段考慮，并必須在整個(gè)開(kāi)發(fā)生命周期中應(yīng)用。這可能不是微服務(wù)特有的概念，但由于它帶來(lái)的顯著好處，必須遵循此概念。
如果您目前正在實(shí)踐DevSecOps，那么您很可能正在遵循左移或安全設(shè)計(jì)原則，在這里您在每個(gè)開(kāi)發(fā)階段都考慮安全性。這不僅有助于在非常早期階段識(shí)別威脅和安全問(wèn)題，而且由于整個(gè)體系結(jié)構(gòu)可以被設(shè)計(jì)為以最小的努力解決安全問(wèn)題，因此還可以減少修復(fù)這些問(wèn)題所需的工作量。
這些架構(gòu)設(shè)計(jì)對(duì)網(wǎng)絡(luò)安全領(lǐng)域并不陌生，多年來(lái)我們已經(jīng)看到其采用率穩(wěn)步增長(zhǎng)。這將我們多年來(lái)一直在使用的多種安全技術(shù)組合成一個(gè)強(qiáng)大的設(shè)計(jì)，能夠減少甚至是最復(fù)雜應(yīng)用程序的攻擊面。
零信任基于一些共同的關(guān)鍵原則，這些原則共同發(fā)揮作用，形成了最安全的應(yīng)用程序部署；其中一些原則是：
由于微服務(wù)獨(dú)立于其他服務(wù)，這種方法非常適合確保即使一個(gè)微服務(wù)被攻破，攻擊者也無(wú)法危及應(yīng)用程序的其余部分。
安全性的最重要方面之一是訪問(wèn)控制，甚至是零信任架構(gòu)背后的關(guān)鍵原則之一，該架構(gòu)要求僅為任何給定實(shí)體分配最小特權(quán)。
將有多個(gè)用戶，如果沒(méi)有多個(gè)賬戶用于允許每個(gè)微服務(wù)與其他微服務(wù)或其他服務(wù)（如數(shù)據(jù)庫(kù)）進(jìn)行通信。在這些部署中，必須分配最小數(shù)量的訪問(wèn)權(quán)限，以允許微服務(wù)執(zhí)行定義的任務(wù)。
此外，如果您使用諸如AWS Lambda之類的解決方案，則建議使用短壽命的憑證，例如“角色”，這樣用戶帳戶必須假定角色才能執(zhí)行任務(wù)，沒(méi)有此角色將沒(méi)有任何本機(jī)權(quán)限。
您可能知道您的微服務(wù)在應(yīng)用程序構(gòu)建到小規(guī)模時(shí)做什么，但是一旦您的應(yīng)用程序增長(zhǎng)并且您的微服務(wù)數(shù)量失控增長(zhǎng)時(shí)，所有這些都會(huì)發(fā)生變化！很快，您將不知道做什么以及理解的任何意義都開(kāi)始消失。
一旦發(fā)生這種情況，您將很可能在架構(gòu)和微服務(wù)內(nèi)留下未計(jì)劃的空白，這些空白允許攻擊者進(jìn)入。
這就是威脅建模派上用場(chǎng)的地方，它允許考慮系統(tǒng)的數(shù)據(jù)流、服務(wù)間通信和外部威脅等多個(gè)方面。
威脅建模使架構(gòu)師能夠可視化和識(shí)別體系結(jié)構(gòu)中存在的各種問(wèn)題，并確保在構(gòu)建應(yīng)用程序之前修復(fù)了已識(shí)別的風(fēng)險(xiǎn)，從而節(jié)省了在開(kāi)發(fā)和測(cè)試階段所花費(fèi)的大量金錢(qián)和時(shí)間。
我們已經(jīng)確認(rèn)微服務(wù)運(yùn)行在不同的語(yǔ)言上，并在單個(gè)微服務(wù)中有多個(gè)組件來(lái)啟用其功能。
漏洞管理是一種被忽視的方法，允許工程師和管理員識(shí)別和修補(bǔ)這些不同組件，無(wú)論是容器基礎(chǔ)架構(gòu)、代碼還是甚至是使用的第三方庫(kù)。
正確的漏洞和補(bǔ)丁管理不僅能夠?qū)崿F(xiàn)安全應(yīng)用程序，而且能夠?qū)崿F(xiàn)嚴(yán)格的合規(guī)性。
這是沒(méi)有人愿意考慮的事情，因?yàn)槊總€(gè)人都忙于保護(hù)他們的應(yīng)用程序。時(shí)代已經(jīng)改變了，規(guī)劃一個(gè)合適的事件響應(yīng)可以幫助您的應(yīng)用程序從攻擊中恢復(fù)。
這是因?yàn)楝F(xiàn)在不再是如果您的應(yīng)用程序受到攻擊，而是WHEN它將受到攻擊，擁有適當(dāng)?shù)氖录憫?yīng)程序?qū)⒂兄跍?zhǔn)備您的應(yīng)用程序和團(tuán)隊(duì)更好地應(yīng)對(duì)特定類型的攻擊。
擁有詳細(xì)的事件響應(yīng)手冊(cè)還可以幫助發(fā)展您的微服務(wù)設(shè)計(jì)，因?yàn)閺闹袑W(xué)到的經(jīng)驗(yàn)可以直接納入應(yīng)用程序的設(shè)計(jì)中。
復(fù)雜的應(yīng)用程序可能有數(shù)百甚至數(shù)千個(gè)微服務(wù)協(xié)同工作，這些功能可能需要使用API密鑰、密碼和其他形式的密鑰以進(jìn)行身份驗(yàn)證。
在應(yīng)用程序中管理數(shù)百個(gè)密鑰變得很麻煩，當(dāng)您需要安全地存儲(chǔ)、使用并輪換每個(gè)密鑰時(shí)，就更是如此。這通常是當(dāng)開(kāi)發(fā)人員變懶，將這些密鑰硬編碼到源代碼中或?qū)⑺鼈兇鎯?chǔ)在配置文件中時(shí)。將密鑰以明文形式存儲(chǔ)是一場(chǎng)災(zāi)難，攻擊者可以簡(jiǎn)單地讀取源代碼或純文本并檢索這些密鑰。
推薦的密鑰管理方法是將所有密鑰存儲(chǔ)在安全的保險(xiǎn)庫(kù)中，例如HashiCorp Vault、AWS Secrets Manager或AWS Systems Manager Parameter Store。這些解決方案使開(kāi)發(fā)人員能夠安全地存儲(chǔ)并根據(jù)需要檢索他們的密鑰，而無(wú)需將它們硬編碼到源代碼中，甚至存儲(chǔ)在配置文件中。
當(dāng)您在保護(hù)微服務(wù)架構(gòu)的所有其他方面時(shí)，一個(gè)關(guān)鍵組件經(jīng)常被忽視。這是運(yùn)行所有微服務(wù)的組件，在大多數(shù)情況下這些是容器！
確保您的容器基礎(chǔ)架構(gòu)得到安全保護(hù)與確保微服務(wù)本身的安全性同樣重要，因?yàn)槿萜靼踩灾械穆┒纯赡苁构粽吣軌蜻M(jìn)入基礎(chǔ)架構(gòu)并從底層破壞應(yīng)用程序。
因此，關(guān)注關(guān)鍵的安全方面，如但不限于容器鏡像、運(yùn)行時(shí)、注冊(cè)表、網(wǎng)絡(luò)和運(yùn)行時(shí)安全性，至關(guān)重要。
此外，關(guān)注供應(yīng)商特定組件，如Kubernetes Pod Security，確保它們根據(jù)規(guī)范進(jìn)行加固，這也將增加您在容器環(huán)境中的安全性。
這個(gè)專用的基礎(chǔ)架構(gòu)層添加到您的微服務(wù)架構(gòu)之上，允許您控制微服務(wù)之間的通信。該層引入了關(guān)鍵組件，如：
所有這些組件在提供對(duì)應(yīng)用程序中流動(dòng)數(shù)據(jù)更多控制方面發(fā)揮著至關(guān)重要的作用。
保護(hù)微服務(wù)架構(gòu)不僅意味著加固各個(gè)組件，還要使架構(gòu)能夠在攻擊或可能出現(xiàn)的其他操作問(wèn)題期間處理故障和錯(cuò)誤。
斷路器模式的概念使應(yīng)用程序能夠?qū)⑻囟ㄎ⒎?wù)與應(yīng)用程序的其余部分隔離開(kāi)來(lái)，如果連續(xù)發(fā)生故障，這種隔離可以使應(yīng)用程序的一部分（取決于哪個(gè)微服務(wù)有問(wèn)題）能夠正常運(yùn)行，但也可以防止資源枯竭。
此外，應(yīng)用程序?qū)⒛軌虼_定故障的微服務(wù)是否已恢復(fù)，通過(guò)優(yōu)雅地嘗試向先前有問(wèn)題的微服務(wù)發(fā)送請(qǐng)求并監(jiān)視其響應(yīng)，而不會(huì)強(qiáng)制整個(gè)負(fù)載到它，這可能會(huì)導(dǎo)致服務(wù)再次失敗。
保護(hù)微服務(wù)并非總是一帆風(fēng)順，需要一些計(jì)劃。然而，通過(guò)正確的技術(shù)、工具和程序的組合，您的基于微服務(wù)的應(yīng)用程序可以更安全、更有抵抗力地抵御攻擊。
本文鏈接：http://www.www897cc.com/showinfo-26-76531-0.html?2024年保護(hù)微服務(wù)的前十種技術(shù)
聲明：本網(wǎng)頁(yè)內(nèi)容旨在傳播知識(shí)，若有侵權(quán)等問(wèn)題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。郵件：2376512515@qq.com
上一篇： C++變量詳解：聲明、定義與作用域
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請(qǐng)聯(lián)系：2376512515@qq.com 津ICP備18001702號(hào)
津公網(wǎng)安備 12010102000574號(hào)