Del 5: Genesis of Ledger Recover - Operationell säkerhet | Huvudbok

Del 5: Genesis of Ledger Recover – Operationell säkerhet | Huvudbok

Hittills har vi i del 1 och 2 visat hur Ledger Recover delar upp ditt frö i aktier och skickar dessa aktier säkert till vänner pålitliga säkerhetskopieringsleverantörer. I del 3 har vi visat hur det går lagrar (och återställer) säkert andelarna av ditt frö, skyddad av hårdvarukryptering, knuten till din identitet och diversifierad. I del 4 har vi utforskat hur Ledger Recover lyckas ge åtkomst till din säkerhetskopia endast för dig och dig.

Det är nu dags att titta närmare på hur vi säkerställer maximal säkerhet på operativ nivå. I ett ögonkast uppnås driftsäkerhet genom att:

  • Förstärkning av infrastrukturen som ligger till grund för Ledger Recover,
  • Tillämpa arbetsuppdelning på de olika operatörerna av Ledger Recover,
  • Övervakning av kritiska komponenter och operationer,
  • Implementera en återställningsspecifik incidentrespons.

Låt oss dyka in i detaljerna om vad var och en av dessa objekt betyder.

Härdning av infrastruktur

Infrastrukturhärdning finns i många former. Det är en 360°-övning som involverar ett brett utbud av aktiviteter som drivs av en grundlig analys av säkerhetsrisker. Det börjar vanligtvis med att upprätthålla en katalog över attackscenarier som kan leda till säkerhetsproblem (som dataläckor, efterbildning av klienter som leder till otillåten återställning av resurser, icke-responsiva system och tjänstavbrott). Förebyggandet av dessa problem på operativ nivå är organiserat kring aktiviteter som resursisolering, systemåtkomstreglering, nätverkstrafikkontroll, sårbarhetshantering och många fler.

Del 5: Genesis of Ledger Recover - Operationell säkerhet | Ledger PlatoBlockchain Data Intelligence. Vertikal sökning. Ai.
Del 5: Genesis of Ledger Recover - Operationell säkerhet | Huvudbok

Här är en sammanfattning av våra viktigaste åtgärder för att förstärka Ledger Recovers infrastruktur:

Tjänstes tillgänglighet

Infrastrukturen är utformad så att det finns no single point of failure (NSPOF), vilket betyder att systemet är motståndskraftigt mot fel på någon komponent. Låt oss ta följande exempel: våra datacenter betjänas av två oberoende internetleverantörer (ISP) i två motsatta ändar av byggnaden. Om fibern skadas på grund av pågående byggarbeten i en del av byggnaden kommer data helt enkelt att dirigeras via den andra Internetleverantören. Störningsfritt underhåll är ytterligare en fördel som ökar tillgängligheten. Med tanke på att det finns minst två instanser av alla programvarukomponenter i Ledger Recover kan vi konfigurera om systemet så att det endast använder instans A medan vi ersätter/uppgraderar/fixar instans B.

Begränsad administratörsåtkomst till Ledger Recover-applikationer

Endast en minskad uppsättning användare ges administratörsbehörighet till resurserna som är dedikerade till Ledger Recover. Ju kortare listan över användare är, desto mer kan vi minska risken för att insiderhot får administratörsåtkomst.

Säkrade fysiska datacenter

Säkerhetskopieringsleverantörernas HSM är värd geografiskt överflödig fysiska datacenter, skyddade från fysiska och virtuella hot som använder branschklassade säkerhetstekniker och -procedurer. Nivån på fysiskt skydd säkerställer att ingen obehörig person kan gå iväg med en HSM. Att förlita sig på datacenter på flera platser innebär att om en plats upplever ett problem kan en annan plats ta över, vilket ger oavbruten tjänsttillgänglighet. Sist men inte minst, det ger oss att hantera våra egna HSM kontroll över vem som har tillgång till dem och vilken kod som används på dem.

Isolering av Ledger Recover-resurser

Alla Ledger Recover-resurser är isolerade från alla andra resurser inom Ledger Recovers tjänsteleverantörer, inklusive inom Coincover och Ledger. Denna isolering behövs för att säkerställa att vi kan innehålla potentiella attacker från en nätverksdel som syftar till att utnyttja resurser från andra nätverksdelar.

Säkerhet på kodnivå säkerställs via flera pelare
  • Vi använder kodläsare för att hjälpa oss att tidigt identifiera och åtgärda sårbarheter och förhindra dem från att ta sig in i produktionen.
  • Koda is Granskad och godkänd by ett team oberoende av den som utvecklar Ledger Recover. Denna separation är ytterligare en åtgärd för att förbättra den övergripande kodkvaliteten genom att fånga upp logiska brister som kan leda till säkerhetsproblem.
  • Koden för kritiska moduler av Ledger Recover är undertecknad med en kryptografisk signatur. Signaturen genereras delvis baserat på kodens innehåll, vilket förhindrar distribution av manipulerad kod genom att jämföra signaturen med dess förväntade värde. Denna säkerhetskontroll görs innan koden exekveras.
Nätverkstrafikkontroll

Nätverkstrafiken kontrolleras noggrant via policyer som definierar regler för trafikflöden för alla tre säkerhetskopieringsleverantörer. Förbi definiera regler för tillåten och nekad trafik, begränsar vi attackytan och minskar risken för obehörig åtkomst. Att begränsa kommunikationen mellan enskilda tjänster säkerställer också att angriparens sidorörelse är begränsad, även om en komponent äventyras. Dessutom tillämpar vi ömsesidig TLS (mTLS)-autentisering för att förhindra Man-in-the-Middle (MiM)-attacker. Genom att verifiera identiteten för båda parter med certifikat säkerställer ömsesidig TLS det endast betrodda enheter kan upprätta en säker anslutning.

Nyckelrotation

kryptering nycklar (används till exempel för att kryptera data eller kommunikation) är ändras regelbundet i linje med bästa praxis för kryptografi. Fördelen med detta är att om en nyckel äventyras skadan är begränsad till tiden mellan rotationer och till data krypterad med den gamla nyckeln.

Utgående trafiksäkerhet

Utgående trafik är begränsad till endast kända domäner och IP-adresser (säkerhetskopieringsleverantörer, tjänsteleverantörer). Att begränsa och övervaka utgående trafik är ett sätt att vara uppmärksam på potentiella dataläckor. Om volymen av utgående dataflöden är högre än förväntat, kan en illvillig aktör extrahera känslig data från Ledger Recover-systemet i betydande omfattning. 

Inkommande trafiksäkerhet

Inkommande trafik skyddas av en kombination av anti-DDoS, webbapplikationsfiltrering (WAF) och IP-filtreringstekniker. Distributed denial-of-service (DDoS)-attacker skadar genom att deras målsystem svämmar över med förfrågningar. Begränsning av antalet inkommande förfrågningar är en välkänd åtgärd mot sådana attacker. Nu handlar inte alla attacker om kvantitet, några av dem handlar om kvalitet. Det är här WAF kommer in i bilden. WAF tittar på inkommande förfrågningar och inspekterar deras avsedda beteende: om begäran syftar till att få obehörig åtkomst eller manipulera data, blockerar filtret begäran. Slutligen använder IP-filtrering den dubbla tekniken av a) vitlistning, det vill säga tillåta trafik endast från specifika IP-adresser eller intervall, och b) svartlistning, det vill säga blockering trafik från kända angripares IP-adresser.       

Sårbarhetshantering

Komponenterna i Ledger Recover-infrastrukturen är kontinuerligt och systematiskt skannade för kända sårbarheter och felkonfigurationer, och patchar/uppdateringar tillämpas regelbundet. Detta hjälper svaret på nya typer av hot när de dyker upp och håller säkerhetsåtgärderna uppdaterade och i världsklass.

Separation av arbetsuppgifter

Arbetsuppdelning är kärnan i Ledger Recovers säkerhetsstrategi. 

Uppdelningen av arbetsuppgifter mellan de olika Säkerhetskopieringsleverantörer (del 3) och IDV-leverantörs (del 4) har beskrivits i tidigare inlägg. Du kanske kommer ihåg att det finns:

  • 3 andelar av Secret Recovery-frasen som hanteras av 3 oberoende säkerhetskopieringsleverantörer (med databasdiversifiering på toppen för att förhindra maskopi)
  • 2 oberoende identitetsvaliderare (IDV-leverantörer)

På infrastrukturnivå, arbetsuppdelning appliceras mellan de olika rollerna som är involverade i utvecklingen och driften av Ledger Recover.

Dessutom kombinerar vi arbetsuppdelningen med "minst privilegium"-principen. "Minsta privilegium" är principen som tillämpas på systemoperatörer och administratörer: de ges rätt att göra bara vad de behöver göra, se till att de ges den lägsta nivån av tillstånd som krävs för att utföra sina uppgifter. 

Så när "minsta privilegium" kombineras med "uppdelning av arbetsuppgifter", olika administratörsroller tilldelas olika personer så att ingen enskild person kan skada/kompromettera konfidentialitet eller integritet för någon systemkomponent. Till exempel har utvecklare av Ledger Recover-kod inte tillgång till systemet som kör koden de skrev.

Del 5: Genesis of Ledger Recover - Operationell säkerhet | Ledger PlatoBlockchain Data Intelligence. Vertikal sökning. Ai.
Del 5: Genesis of Ledger Recover - Operationell säkerhet | Huvudbok
Styrning: Kvorum

I likhet med Blockchains konsensusmekanismer som garanterar integritet och säkerhet genom att låta flera aktörer verifiera block, har vi antagit ett kvorum inom Ledger Recover-systemet för att förbättra vår operativa säkerhet.

Trots våra robusta bakgrundskontroller för våra anställda kvarstår faktum att människor kan vara en svag länk i alla system, och kryptosfären är inget undantag. Högprofilerade säkerhetsincidenter, såsom Mount Gox hack från 2014, visa hur individer kan utnyttjas eller leda till säkerhetsbortfall. Människor kan påverkas eller tvingas genom olika motiv – pengar, ideologi, tvång, ego (aka, MICE(S)) – vilket gör även de mest stränga bakgrundskontrollerna inte helt idiotsäkra.

För att minska sådana risker använder vi ett system baserat på konceptet beslutförhet. Detta ramverk kräver samförstånd från minst tre auktoriserade personer från olika team eller avdelningar inom backup-leverantörer innan några betydande beslut eller kritiska åtgärder kan vidtas. 

Det exakta antalet personer som är involverade i våra olika kvorum förblir inte avslöjat av säkerhetsskäl. Ändå förbättrar dess existens avsevärt vår operativa säkerhet genom att späda på det potentiella inflytandet från en enskild individ som är utsatt för intrång.

Här är några av aktiviteterna där vi använder kvorum:

1. Generera de privata nycklarna för Ledger Recover HSMs: Denna kritiska operation skyddas av oberoende kvorum inom varje enhet – Coincover, EscrowTech och Ledger. Varje medlem av dessa distinkta kvorum måste vara närvarande för att generera privata nycklar i sina respektive HSM:er. Varje kvorummedlem har tillgång till en reservnyckel, vilket är avgörande för att återställa och återskapa sina HSM-hemligheter om det behövs. Denna struktur skyddar inte bara mot risken för att någon person har otillbörligt inflytande över en av de tre säkerhetskopieringsleverantörernas HSM:er utan förbättrar också den övergripande systemets integritet eftersom varje kvorum fungerar oberoende och är omedvetet om varandras detaljer.

Del 5: Genesis of Ledger Recover - Operationell säkerhet | Ledger PlatoBlockchain Data Intelligence. Vertikal sökning. Ai.
Del 5: Genesis of Ledger Recover - Operationell säkerhet | Huvudbok
Tänk på att inte ens ett helt kompromissat kvorum kan utsätta användarnas tillgångar på spel. Minns från blogginlägg 2: Varje backup-leverantör hanterar endast en enskild resurs. Utan alla nödvändiga resurser är det omöjligt att rekonstruera en användares frö. 

Att extrahera den privata nyckeln för HSM, som behövs för att dechiffrera befintliga andelar, kan dessutom inte göras med kvorumets reservnycklar. Säkerhetskopieringsleverantörens kvorummedlemmar kommer bara att kunna återställa och återskapa en ny HSM.

2. Beslut om en exceptionell frigivning av en kunds andel: Specifika, om än sällsynta, situationer kan kräva en exceptionell frigivning av en kunds andel. Dessa kan bero på identitetsverifieringsfel (namnändring, fysisk vanställning, etc.), eller om våra hemliga säkerhetsåtgärder felaktigt blockerar en enhet. När en sådan situation uppstår kommer ett beslutförhet som består av flera personer från backup-leverantörerna samman. Detta förfarande, som kräver bred konsensus, säkerställer att beslut inte fattas hastigt eller ensidigt, vilket ökar kundsäkerheten. Varje medlem i kvorumet använder sin Ledger Nano-enhet (med sin egen pin) för att godkänna utgivningen, vilket lägger till ytterligare ett lager av säkerhet mot eventuell maskopi eller individuella fel.

3. Signerar uppdatering av HSM firmwarekod: Innan vi distribuerar en ny firmwareuppdatering till HSM:erna genomför vårt produktsäkerhetsteam, Ledger Donjon, en omfattande granskningsprocess. Som en del av den fasta programvarans kvorum säkerställer Ledger Donjon att inga bakdörrar eller skadlig kod har introducerats av en illvillig insider eller en komprometterad utvecklingspipeline via supply chain attack. På så sätt bibehåller de integriteten och säkerheten för firmwareuppdateringen.

4. Uppdatering av firmwarekod för signering av Ledger-enheter (Nano & Stax): Ungefär som den fasta programvaran för HSM:erna går uppdateringar av vår Ledger-enhets firmware igenom en strikt granskningsprocess och kräver godkännande av kvorum innan de föreslås till våra användare via Ledger Live.

Avslutningsvis är kvorum en integrerad del av Ledger Recovers säkerhetsarkitektur. De spelar en viktig roll när det gäller att stärka försvaret mot interna oseriösa hot och maskopi under viktiga operationer. Genom att utnyttja den förstklassiga säkerheten för Ledger-enheter och tjänster, hjälper kvorum att säkerställa förtroende och skydda användarnas digitala tillgångar mot illvilliga insiders.

Övervakning av kritiska komponenter och operationer

När vi går in i det här kapitlet är det viktigt att notera att vi av säkerhetsskäl endast avslöjar en delmängd av de omfattande övervakningsaktiviteterna för Ledger Recover-tjänsten. Samtidigt som vi står fast vid vårt engagemang för transparens, inser vi också vikten av att behålla diskretion kring detaljerna i de interna kontrollerna och övervakningen av operativ säkerhet.

Hos Ledger är säkerhet vår prioritet. Det är kärnan i våra lösningar, som bygger på robusta kryptografiska protokoll som beskrivs i vår Ledger Recover whitepaper. Men vårt arbete fortsätter bortom skapandet av säkra system. Vi övervakar och utvärderar ständigt vår verksamhet och letar efter eventuella misstänkta aktiviteter. Denna kontinuerliga vaksamhet stärker vår säkerhetsinställning och säkerställer att vi alltid är redo att svara. 

Låt oss utforska några exempel på vår flerskiktsstrategi:

Övervaka administratörsaktiviteter: Vi tillämpar strikt åtkomstkontroll för våra administratörer. Vi kräver inte bara 2FA (Two-Factor Authentication) för alla administrativa anslutningar till vår infrastruktur, utan vi kräver också validering av flera personer för åtkomst till administratörsinfrastruktur på kritiska delar av systemet. Dessutom loggar och spårar våra system noggrant varje administrativ aktivitet. Dessa loggar korsreferens automatiskt med våra interna biljettsystem för att upptäcka eventuella oplanerade åtgärder. Denna försiktiga korrelation gör det möjligt för oss att omedelbart varna våra säkerhetsteam om ovanligt eller misstänkt beteende, vilket förstärker vår operativa säkerhet.

Korskontroll bland leverantörer av säkerhetskopiering: Transparens och ansvarsskyldighet ligger till grund för relationerna mellan backup-leverantörerna, Ledger, EscrowTech och Coincover. Vi har etablerat ett realtidsutbyte av loggar som används för systemövervakning och säkerhet. Detta möjliggör korsverifiering av aktiviteter. Om någon inkonsekvens upptäcks låses tjänsten omedelbart för att skydda användarnas tillgångar.

Övervaka exceptionell releaseaktivitet: De sällsynta fallen av manuella aktiesläpp är noggrant kontrollerade genom en process med flera kvorum som vi förklarade i föregående avsnitt. Efter utförandet av den exceptionella frigivningsaktiviteten fortsätter Ledger Recover-systemen med omfattande övervakning, inklusive detaljerad loggning och analys av de inblandade parterna, drifttid och andra relevanta detaljer. Denna process, som involverar både verkställande av flera kvorum och övervakning efter åtgärd, säkerställer att den exceptionella frigivningen av aktier är noggrant kontrollerad i alla skeden av beslutsprocessen.

Utnyttja säkerhetsinformation och händelsehantering (SIEM): SIEM-lösningen utgör en avgörande del av övervakningsstrategin Ledger Recover. Denna dedikerade SIEM förbättrar förmågan att identifiera och reagera på potentiella säkerhetsproblem i realtid. Den är finjusterad för att identifiera en mängd kompromissindikatorer (IoC) baserade på kluster- och Ledger Recover-programloggar, tack vare specifika detektionsregler som är speciellt utvecklade för Ledger Recover-tjänsten. Om en anpassad IoC upptäcks sker ett automatiskt och omedelbart svar – hela klustret är låst tills en grundlig analys genomförs. I Ledger Recover-tjänsten prioriteras konfidentialitet framför tillgängligheten av tjänsten för att säkerställa det yttersta skyddet av användarnas tillgångar.

I det dynamiska landskapet av cybersäkerhet har vi lagt strategier och förberett oss för olika scenarier. Vår hotmodell står för den osannolika situationen där flera infrastrukturadministratörer från olika säkerhetskopieringsleverantörer kan äventyras. Med rigorösa säkerhetsåtgärder och automatiska svar på plats syftar Ledger Recover-tjänsten till att säkerställa den fortsatta säkerheten för användarnas tillgångar även under sådana extraordinära omständigheter. I följande avsnitt kommer vi att beskriva de omfattande svarsåtgärderna som byggts för att hantera sådana hypotetiska situationer.

Ledger Recover-specifik incidentrespons

Med Ledger Recover-tjänsten har en Incident Response-strategi byggts upp, i samarbete med de tre backupleverantörerna. En central del av denna strategi är automatiska säkerhetsåtgärder som omedelbart låser hela systemet vid upptäckt av misstänkt aktivitet i någon del av infrastrukturen. 

I huvudsak har ett "alltid säkert, aldrig förlåt"-protokoll konstruerats i Ledger Recover-tjänsten. Säkerhet är högsta prioritet, och det är ett åtagande som aldrig kommer att kompromissas med. 

Även om vi ständigt strävar efter att tillhandahålla en sömlös användarupplevelse för nästa 100 miljoner människor i Web3, kommer vi aldrig att tveka att aktivera dessa skyddsåtgärder, effektivt låsa ner hela Ledger Recover-tjänsten, om ett potentiellt hot uppstår. I vårt uppdrag att skydda är valet mellan att köra en potentiellt komprometterad tjänst och säkerställa ultimat säkerhet tydligt – vi väljer säkerhet.

Slutsats

Här är vi i slutet av Operational Security-delen av denna serie. I den här delen har vi försökt svara på alla bekymmer du kan ha angående hur ogenomträngligheten av Ledger Recover-systemets säkerhetsåtgärder säkerställs. Vi pratade om infrastrukturen, uppdelningen av arbetsuppgifter, styrning och övervakning, och slutligen Incident Response-strategin. 

Tack än en gång för att du läste hela vägen fram till denna punkt! Du bör nu ha en omfattande förståelse för Ledger Recovers driftsäkerhet. Den sista delen av den här blogginläggsserien kommer att handla om de senaste säkerhetsproblemen vi hade, och mer exakt: hur hanterade vi våra interna och externa säkerhetsrevisioner för att garantera maximal säkerhetsnivå för våra användare? Håll ögonen öppna! 

Tidsstämpel:

Mer från Ledger