建站
咨詢(xún)
售后
建站咨詢(xún)
新聞中心
開(kāi)發(fā)可靠的分布式系統(tǒng)的一個(gè)基本挑戰(zhàn)是支持執(zhí)行共同任務(wù)所需的分散實(shí)體的合作，即使某些這些實(shí)體或它們之間的通信失敗。需要確保服務(wù)操作的順序，并避免對(duì)分布式資源進(jìn)行分區(qū)，以便形成一個(gè)整體的“協(xié)調(diào)”資源組。
狀態(tài)機(jī)復(fù)制或狀態(tài)機(jī)方法是通過(guò)復(fù)制服務(wù)器和協(xié)調(diào)客戶(hù)端與服務(wù)器副本的交互來(lái)實(shí)現(xiàn)容錯(cuò)服務(wù)的通用方法。該方法還為理解和設(shè)計(jì)復(fù)制管理協(xié)議提供了一個(gè)框架。基本的系統(tǒng)抽象是狀態(tài)機(jī)的抽象，使得狀態(tài)機(jī)的輸出完全由它處理的請(qǐng)求序列決定，而與時(shí)間或其他活動(dòng)無(wú)關(guān)。系統(tǒng)。復(fù)制可以是主動(dòng)的、半主動(dòng)的、被動(dòng)的或惰性的。
應(yīng)該注意的是，理想情況下，人們希望共同實(shí)現(xiàn)高可用性、一致性和完全協(xié)調(diào)，以消除分布式資源集的任何分區(qū)。但是，CAP斷言的作用是：
CAP
任何網(wǎng)絡(luò)共享數(shù)據(jù)系統(tǒng)（例如Web）只能提供3種可能屬性中的2種，如下所示：
1.一致性（C）：相當(dāng)于擁有數(shù)據(jù)的單個(gè)最新副本，即每個(gè)服務(wù)器對(duì)每個(gè)請(qǐng)求返回正確的響應(yīng)。
2.可用性（A）：每個(gè)請(qǐng)求最終收到響應(yīng)的數(shù)據(jù)。
3.分區(qū)（P）：網(wǎng)絡(luò)分區(qū)容錯(cuò)，使得服務(wù)器無(wú)法分區(qū)為非通信組。
當(dāng)然，安全攻擊會(huì)試圖破壞CAP的這些元素。
復(fù)制和協(xié)調(diào)
為了提供一致和一致的行為（在值和順序上），分布式資源使用各種類(lèi)型的副本管理，即協(xié)調(diào)模式。這是表征任何分布式系統(tǒng)功能的關(guān)鍵協(xié)調(diào)機(jī)制。決定特定機(jī)制的因素取決于系統(tǒng)同步模型的類(lèi)型、組通信的類(lèi)型，尤其是所考慮的擾動(dòng)（故障或攻擊）的性質(zhì)。這些機(jī)制可以是簡(jiǎn)單的投票或領(lǐng)導(dǎo)者選舉過(guò)程（例如，環(huán)形算法，欺凌），也可以是更復(fù)雜的共識(shí)方法來(lái)處理崩潰或拜占庭5行為。數(shù)據(jù)庫(kù)事務(wù)的提交協(xié)議與提供經(jīng)過(guò)驗(yàn)證的訪(fǎng)問(wèn)控制的憑據(jù)管理和PKI基礎(chǔ)結(jié)構(gòu)的方案在這里相關(guān)。我們簡(jiǎn)要描述了一組廣泛使用的模式，并參考閱讀器以完整覆蓋。分布式系統(tǒng)中的授權(quán)和身份驗(yàn)證也在身份驗(yàn)證，授權(quán)和責(zé)任CyBOK知識(shí)領(lǐng)域中進(jìn)行了討論。
Paxos
為了避免分布式實(shí)體進(jìn)行不協(xié)調(diào)的行動(dòng)或未能響應(yīng)的情況，Paxos已經(jīng)開(kāi)發(fā)出來(lái)，這是一組隱式領(lǐng)導(dǎo)者選舉協(xié)議，用于在異步設(shè)置中解決共識(shí)。Paxos通過(guò)讓所有參與者在初始階段提出一個(gè)達(dá)成一致的價(jià)值來(lái)解決共識(shí)問(wèn)題。在第二階段，如果多數(shù)人同意某個(gè)價(jià)值，則提出該價(jià)值的過(guò)程隱含地成為領(lǐng)導(dǎo)者，并達(dá)成一致。對(duì)下一個(gè)值重復(fù)相同的過(guò)程，以就一系列值達(dá)成共識(shí)。
眾所周知，該方案僅在非常特定的情況下才提供活體。在這種情況下，流程繼續(xù)無(wú)限期地提出價(jià)值，并在初始階段保持阻塞，因?yàn)闊o(wú)法形成多數(shù)并且從未取得進(jìn)展。然而，這種情況在實(shí)踐中很少發(fā)生，Paxos仍然是使用最廣泛的協(xié)調(diào)協(xié)議之一。
由于在第二階段只需要多數(shù)人即可達(dá)成共識(shí)，因此即使在恢復(fù)的情況下，該協(xié)議也對(duì)崩潰具有容忍度。這是了不起的，因?yàn)橹灰蠖鄶?shù)進(jìn)程沒(méi)有失敗，就能夠達(dá)成共識(shí)。
雖然Paxos協(xié)議有多種實(shí)現(xiàn)方式，但由于其固有的復(fù)雜性，它以難以實(shí)現(xiàn)和構(gòu)建中間件而聞名。為此，提出了一種類(lèi)似于Paxos的協(xié)議RAFT來(lái)提供相同的保證。RAFT最近因其更簡(jiǎn)單的設(shè)計(jì)而越來(lái)越受歡迎。通過(guò)與Paxos的比較，解釋了RAFT協(xié)議開(kāi)發(fā)背后的動(dòng)機(jī)以及它是如何工作的。
拜占庭容錯(cuò)（BFT）
攻擊和其他故意中斷不一定遵循良性遺漏、時(shí)間或崩潰的語(yǔ)義。為了容忍任意惡意行為，拜占庭容錯(cuò)（BFT）協(xié)議使用協(xié)調(diào)復(fù)制來(lái)保證操作的正確執(zhí)行，只要在大多數(shù)三分之一的進(jìn)程受到損害并表現(xiàn)出任意（即拜占庭，參見(jiàn)第5節(jié)）行為。
在BFT中，進(jìn)程以輪次交換它們從彼此那里收到的值。達(dá)成共識(shí)所需的輪數(shù)取決于系統(tǒng)中受損參與者的數(shù)量。請(qǐng)注意，由于該協(xié)議是輪次運(yùn)行的，因此它被歸類(lèi)為同步協(xié)調(diào)協(xié)議。已經(jīng)表明，F(xiàn)LP不可能的結(jié)果是在異步通信的情況下不可能達(dá)成共識(shí)。由于同步通信的必要性以及處理拜占庭故障所需的消息交換開(kāi)銷(xiāo)相當(dāng)高，BFT協(xié)議主要應(yīng)用于特定的關(guān)鍵應(yīng)用。然而，通過(guò)加強(qiáng)對(duì)同步、確定性和妥協(xié)數(shù)量的一些基本假設(shè)，正在進(jìn)行多種實(shí)際BFT優(yōu)化的嘗試。Google File System（Chubby）和Amazon Web Services（AWS）實(shí)現(xiàn)了Paxos和部分BFT功能。同樣重要的是要強(qiáng)調(diào)BFT不僅因?yàn)樗栎啍?shù)的消息復(fù)雜性而昂貴。處理f惡意故障所需的節(jié)點(diǎn)數(shù)（>f）也是昂貴的，即f是由對(duì)手控制的節(jié)點(diǎn)數(shù)。
從安全角度來(lái)看，BFT協(xié)議能夠容忍任意惡意行為，因此構(gòu)成了構(gòu)建入侵容忍系統(tǒng)的有吸引力的構(gòu)建塊。值得注意的是，這些協(xié)議考慮了受感染實(shí)體的數(shù)量。當(dāng)面對(duì)惡意攻擊者時(shí)，相同的副本是不夠的，因?yàn)樗鼈儽憩F(xiàn)出相同的漏洞。如果其他副本相同，則可以破壞一個(gè)副本的惡意攻擊者可以輕松破壞它們。需要復(fù)制和多樣性（或不同的保護(hù)方法）。
提交協(xié)議
許多應(yīng)用程序，例如數(shù)據(jù)庫(kù)，需要跨復(fù)制的數(shù)據(jù)或操作進(jìn)行排序，其中所有參與者都同意執(zhí)行相同的正確結(jié)果（即提交）或不執(zhí)行任何操作–原子性屬性。因此，作為一種專(zhuān)門(mén)的共識(shí)形式，需要分布式協(xié)調(diào)器定向算法來(lái)協(xié)調(diào)參與分布式原子事務(wù)的所有進(jìn)程是否以提交或中止（回滾）事務(wù)。
兩階段提交（2PC）是這種原子提交協(xié)議的一個(gè)簡(jiǎn)單示例。該協(xié)議繼續(xù)進(jìn)行從領(lǐng)導(dǎo)者到所有要提交的客戶(hù)端的廣播查詢(xún)。隨后是來(lái)自每個(gè)客戶(hù)端的確認(rèn)（提交或中止）。在收到所有響應(yīng)時(shí)，領(lǐng)導(dǎo)者會(huì)通知所有客戶(hù)端關(guān)于提交或中止的原子決策。即使在許多故障情況下（涉及進(jìn)程、網(wǎng)絡(luò)節(jié)點(diǎn)或通信故障等），該協(xié)議也能實(shí)現(xiàn)其目標(biāo)，因此被廣泛使用?；谌罩居涗泤f(xié)議狀態(tài)的方法用于支持恢復(fù)。經(jīng)典的2PC協(xié)議對(duì)可能導(dǎo)致不一致的協(xié)調(diào)器故障提供有限的支持。
為了解決這個(gè)問(wèn)題，開(kāi)發(fā)了三階段提交（3PC）協(xié)議。3PC協(xié)議本質(zhì)上是BFT協(xié)議的擴(kuò)展，并增加了第三個(gè)通信階段，以幫助領(lǐng)導(dǎo)者做出中止的決定。這需要更高的消息傳遞和日志記錄開(kāi)銷(xiāo)來(lái)支持恢復(fù)。雖然與BFT相比，3PC是一種更強(qiáng)大的協(xié)議，但由于消息傳遞開(kāi)銷(xiāo)及其對(duì)網(wǎng)絡(luò)分區(qū)的敏感性（即P大寫(xiě)）。在實(shí)踐中，系統(tǒng)使用BFT是為了簡(jiǎn)單性，或者使用Paxos協(xié)議來(lái)表示其魯棒性。
文章標(biāo)題：分布式系統(tǒng)安全之?復(fù)制管理和協(xié)調(diào)架構(gòu)：攻擊緩解背后的基礎(chǔ)
鏈接分享：http://www.5511xx.com/article/cdiehcd.html
