Del 5: Genesis of Ledger Recover - Operationel sikkerhed | Hovedbog

Del 5: Genesis of Ledger Recover – Operationel sikkerhed | Hovedbog

Indtil videre har vi vist i del 1 og 2, hvordan Ledger Recover opdeler dit frø i aktier , sender disse aktier sikkert til venner betroede backup-udbydere. I del 3 har vi vist, hvordan det går opbevarer (og genopretter) sikkert andelene af dit frø, beskyttet af hardwarekryptering, bundet til din identitet og diversificeret. I del 4 har vi undersøgt, hvordan Ledger Recover formår at give adgang til din backup kun til dig og dig.

Det er nu tid til at se nærmere på, hvordan vi sikrer maksimal sikkerhed på det operationelle niveau. Med et overblik opnås driftssikkerhed ved at:

  • Hærdning af infrastrukturen, der understøtter Ledger Recover,
  • Anvendelse af adskillelse af opgaver til de forskellige operatører af Ledger Recover,
  • Overvågning af kritiske komponenter og operationer,
  • Implementering af en Recover-specifik Incident Response.

Lad os dykke ned i detaljerne om, hvad hver af disse elementer betyder.

Hærdning af infrastruktur

Infrastrukturhærdning kommer i mange former. Det er en 360° øvelse, der involverer en bred vifte af aktiviteter drevet af en grundig analyse af sikkerhedsrisici. Det starter normalt med at vedligeholde et katalog over angrebsscenarier, der kan føre til sikkerhedsproblemer (såsom datalæk, efterligning af klienter, der fører til uautoriseret gendannelse af shares, ikke-responsive systemer og serviceafbrydelser). Forebyggelsen af ​​disse problemer på operationelt niveau er organiseret omkring aktiviteter som ressourceisolering, systemadgangsregulering, netværkstrafikkontrol, sårbarhedsstyring og mange flere.

Del 5: Genesis of Ledger Recover - Operationel sikkerhed | Ledger PlatoBlockchain Data Intelligence. Lodret søgning. Ai.
Del 5: Genesis of Ledger Recover - Operationel sikkerhed | Hovedbog

Her er en oversigt over vores vigtigste foranstaltninger til at hærde Ledger Recovers infrastruktur:

Service tilgængelighed

Infrastrukturen er designet, så der er intet enkelt fejlpunkt (NSPOF), hvilket betyder, at systemet er modstandsdygtigt over for fejl på enhver komponent. Lad os tage følgende eksempel: vores datacentre betjenes af to uafhængige internetudbydere (ISP'er) i to modsatte ender af bygningen. Hvis fiberen er beskadiget på grund af igangværende byggearbejde i den ene del af bygningen, vil data blot blive dirigeret gennem den anden internetudbyder. Afbrydelsesfri vedligeholdelse er endnu en fordel, der øger tilgængeligheden. Da der er mindst to forekomster af alle softwarekomponenter i Ledger Recover, kan vi omkonfigurere systemet til kun at bruge forekomst A, mens vi erstatter/opgraderer/retter forekomst B.

Begrænset administratoradgang til Ledger Recover-applikationer

Kun a reduceret antal brugere tildeles administratoradgang til de ressourcer, der er dedikeret til Ledger Recover. Jo kortere listen over brugere er, jo mere kan vi reducere risikoen for, at insidertrusler får administratoradgang.

Sikrede fysiske datacentre

Backup-udbydernes HSM'er er hostet i geografisk overflødig fysiske datacentre, beskyttet mod fysiske og virtuelle trusler vha sikkerhedsteknikker og -procedurer i brancheklasse. Niveauet af fysisk beskyttelse sikrer, at ingen uautoriseret person tilfældigt kan gå væk med en HSM. At stole på datacentre på tværs af flere websteder betyder, at hvis en placering oplever et problem, kan en anden placering tage over, hvilket giver uafbrudt servicetilgængelighed. Sidst men ikke mindst giver det os at administrere vores egne HSM'er kontrol over, hvem der har adgang til dem og hvilken kode der er implementeret på dem.

Isolering af Ledger Recover-ressourcer

Alle Ledger Recover-ressourcer er isoleret fra alle andre ressourcer hos Ledger Recovers tjenesteudbydere, inklusive inden for Coincover og Ledger. Denne isolation er nødvendig for at sikre, at vi kan indeholde potentielle angreb fra et netværksudsnit, der sigter mod at udnytte ressourcer fra andre netværksudsnit.

Sikkerhed på kodeniveau sikret via flere søjler
  • Vi anvender kode scannere at hjælpe os med at identificere og adressere sårbarheder tidligt og forhindre dem i at komme ind i produktionen.
  • Kode is revideret og godkendt by et team uafhængigt af den, der udvikler Ledger Recover. Denne adskillelse er endnu en foranstaltning til at hjælpe med at forbedre den overordnede kodekvalitet ved at fange logiske fejl, der kan føre til sikkerhedsproblemer.
  • Koden til kritiske moduler af Ledger Recover er underskrevet med en kryptografisk signatur. Signaturen er delvist genereret baseret på kodens indhold, hvilket forhindrer implementering af manipuleret kode ved at sammenligne signaturen med dens forventede værdi. Dette sikkerhedstjek udføres før koden udføres.
Netværk trafikkontrol

Netværkstrafik er stramt styret via politikker, der definerer regler for trafikstrømme for alle 3 backup-udbydere. Ved definere regler for tilladt og nægtet trafik, begrænser vi angrebsfladen og reducerer risikoen for uautoriseret adgang. Begrænsning af kommunikation mellem individuelle tjenester sikrer også, at angriberens sidebevægelse er begrænset, selvom en komponent er kompromitteret. Derudover anvender vi gensidig TLS (mTLS)-godkendelse for at forhindre Man-in-the-Middle (MiM)-angreb. Ved at verificere identiteten af ​​begge parter med certifikater sikrer gensidig TLS det kun betroede enheder kan etablere en sikker forbindelse.

Nøgle rotation

Kryptering nøgler (bruges f.eks. til at kryptere data eller kommunikation) er ændres regelmæssigt i overensstemmelse med bedste praksis for kryptografi. Fordelen ved dette er, at hvis en nøgle bliver kompromitteret skaden er begrænset til tiden mellem rotationer og til de data, der er krypteret med den gamle nøgle.

Udgående trafiksikkerhed

Udgående trafik er begrænset til kun kendte domæner og IP-adresser (backup-udbydere, tjenesteudbydere). Begrænsning og overvågning af udgående trafik er en måde at vær opmærksom på potentielle datalæk. Hvis mængden af ​​udgående datastrømme er højere end forventet, kan en ondsindet aktør muligvis udtrække følsomme data fra Ledger Recover-systemet i betydelig skala. 

Indgående trafiksikkerhed

Indgående trafik er beskyttet af en kombination af anti-DDoS, webapplikationsfiltrering (WAF) og IP-filtreringsteknikker. Distribuerede denial-of-service (DDoS)-angreb udøver skade ved at overfylde deres målsystem med anmodninger. Begrænsning af antallet af indgående anmodninger er en velkendt foranstaltning mod sådanne angreb. Nu er det ikke alle angreb, der handler om kvantitet, nogle af dem handler om kvalitet. Det er her WAF kommer ind i billedet. WAF ser på indkomne forespørgsler og inspicerer deres tilsigtede adfærd: hvis anmodningen sigter mod at få uautoriseret adgang eller manipulere data, blokerer filteret anmodningen. Endelig anvender IP-filtrering den dobbelte teknik af a) whitelisting, altså at tillade trafik kun fra specifikke IP-adresser eller områder, og b) sortlistning, altså blokering trafik fra kendte hacker-IP'er.       

Sårbarhedshåndtering

Komponenterne i Ledger Recover-infrastrukturen er kontinuerligt og systematisk scannet for kendte sårbarheder og fejlkonfiguration, og patches/opdateringer anvendes regelmæssigt. Dette hjælper med at reagere på nye typer trusler, efterhånden som de dukker op, og holder sikkerhedsforanstaltningerne opdaterede og i verdensklasse.

Adskillelse af opgaver

Adskillelse af opgaver er kernen i Ledger Recovers sikkerhedsstrategi. 

Funktionsadskillelsen mellem de forskellige Sikkerhedskopieringsudbydere (del 3) og IDV udbyders (del 4) er blevet beskrevet i de tidligere indlæg. Du kan huske, at der er:

  • 3 andele af den hemmelige gendannelsessætning administreret af 3 uafhængige sikkerhedskopieringsudbydere (med databasediversificering på toppen for at forhindre hemmeligt samarbejde)
  • 2 uafhængige identitetsvalidatorer (IDV-udbydere)

På infrastrukturniveau, adskillelse af opgaver anvendes mellem de forskellige roller, der er involveret i udvikling og drift af Ledger Recover.

Derudover kombinerer vi adskillelsen af ​​opgaver med "mindst privilegium"-princippet. "Mindste privilegium" er princippet, der anvendes på systemoperatører og administratorer: de får kun rettigheder til at gøre, hvad de skal gøre, der sikrer, at de får det laveste niveau af tilladelse, der kræves for at udføre deres opgaver. 

Så når "mindst privilegium" er kombineret med "adskillelse af opgaver", forskellige administratorroller er tildelt forskellige personer så ingen enkelt person kan beskadige/kompromittere fortroligheden eller integriteten af ​​nogen systemkomponent. For eksempel har udviklere af Ledger Recover-kode ikke adgang til det system, der kører den kode, de skrev.

Del 5: Genesis of Ledger Recover - Operationel sikkerhed | Ledger PlatoBlockchain Data Intelligence. Lodret søgning. Ai.
Del 5: Genesis of Ledger Recover - Operationel sikkerhed | Hovedbog
Styring: Kvorum

I lighed med Blockchains' konsensusmekanismer, der garanterer integritet og sikkerhed ved at få flere aktører til at verificere blokke, har vi vedtaget et quorum inden for Ledger Recover-systemet for at forbedre vores operationelle sikkerhed.

På trods af vores robuste baggrundstjek for vores medarbejdere, er det et faktum, at mennesker kan være et svagt led i ethvert system, og kryptosfæren er ingen undtagelse. Højprofilerede sikkerhedshændelser, såsom Mt. Gox hack fra 2014, demonstrere, hvordan individer kan udnyttes eller føre til sikkerhedsbrud. Folk kan blive påvirket eller tvunget gennem forskellige motivationer - Penge, Ideologi, Tvang, Ego (alias MICE(S)) - hvilket gør selv de mest strenge baggrundstjek ikke helt idiotsikre.

For at mindske sådanne risici bruger vi et system baseret på konceptet om et kvorum. Denne ramme kræver konsensus fra mindst tre autoriserede personer fra forskellige teams eller afdelinger inden for backup-udbydere, før der kan tages væsentlige beslutninger eller kritiske handlinger. 

Det nøjagtige antal personer involveret i vores forskellige kvorummer forbliver uoplyst af sikkerhedsmæssige årsager. Alligevel øger dens blotte eksistens væsentligt vores operationelle sikkerhed ved at udvande den potentielle indflydelse fra et enkelt kompromitteret individ.

Her er nogle af de aktiviteter, hvor vi bruger kvorummer:

1. Generering af de private nøgler til Ledger Recover HSM'er: Denne kritiske operation er sikret af uafhængige kvorummer inden for hver enhed - Coincover, EscrowTech og Ledger. Hvert medlem af disse distinkte kvorummer skal være til stede for at generere private nøgler i deres respektive HSM'er. Hvert kvorumsmedlem har adgang til en backupnøgle, som er afgørende for at gendanne og genskabe deres HSM-hemmeligheder, hvis det er nødvendigt. Denne struktur beskytter ikke kun mod risikoen for, at nogen person har unødig indflydelse på en af ​​de tre backup-udbydere HSM'er, men forbedrer også den overordnede systemintegritet, da hvert kvorum opererer uafhængigt og er uvidende om hinandens detaljer.

Del 5: Genesis of Ledger Recover - Operationel sikkerhed | Ledger PlatoBlockchain Data Intelligence. Lodret søgning. Ai.
Del 5: Genesis of Ledger Recover - Operationel sikkerhed | Hovedbog
Husk, at selv et fuldt kompromitteret kvorum ikke kan bringe brugeraktiver i fare. Husk fra blogindlæg 2: Hver backup-udbyder håndterer kun en enkelt share. Uden alle de nødvendige shares er det umuligt at rekonstruere en brugers frø. 

Desuden kan udtrækning af den private nøgle til HSM, som er nødvendig for at dechifrere eksisterende aktier, ikke ske med kvorumets backup-nøgler. Sikkerhedskopieringsudbyderens kvorumsmedlemmer vil kun være i stand til at gendanne og genskabe en ny HSM.

2. Beslutning om en ekstraordinær frigivelse af en kundes andel: Specifikke, omend sjældne, situationer kan kræve en ekstraordinær frigivelse af en kundes andel. Disse kan skyldes identitetsbekræftelsesfejl (navneændring, fysisk vansiring osv.), eller hvis vores ikke-offentliggjorte sikkerhedsforanstaltninger fejlagtigt blokerer en enhed. Når en sådan situation opstår, samles et beslutningsdygtigt antal personer fra backup-udbyderne. Denne procedure, der kræver bred konsensus, sikrer, at beslutninger ikke træffes hastigt eller ensidigt, hvilket øger kundesikkerheden. Hvert medlem af kvorummet bruger deres Ledger Nano-enhed (med deres egen pin) til at godkende udgivelsen, hvilket tilføjer endnu et lag af sikkerhed mod mulige aftaler eller individuelle fejl.

3. Signering af HSM-firmwarekodeopdatering: Før vi implementerer en ny firmwareopdatering til HSM'erne, udfører vores produktsikkerhedsteam, Ledger Donjon, en omfattende gennemgangsproces. Som en del af firmware-quorumet sikrer Ledger Donjon, at ingen bagdøre eller ondsindet kode er blevet introduceret af en ondsindet insider eller en kompromitteret udviklingspipeline via forsyningskædeangreb. På den måde bevarer de integriteten og sikkerheden af ​​firmwareopdateringen.

4. Signering af Ledger-enheder (Nano & Stax) firmwarekodeopdatering: Ligesom firmwaren til HSM'erne gennemgår opdateringer til vores Ledger-enheds firmware en streng gennemgangsproces og kræver quorum-godkendelse, før de foreslås til vores brugere via Ledger Live.

Afslutningsvis er kvorummer en integreret del af Ledger Recovers sikkerhedsarkitektur. De spiller en vigtig rolle i at styrke forsvaret mod interne slyngelstatiske trusler og samordning under vitale operationer. Ved at udnytte den førsteklasses sikkerhed for Ledger-enheder og -tjenester hjælper kvorummer med at sikre tillid og beskytte brugernes digitale aktiver mod ondsindede insidere.

Overvågning af kritiske komponenter og operationer

Når vi dykker ned i dette kapitel, er det vigtigt at bemærke, at vi af sikkerhedsmæssige årsager kun afslører en delmængde af de omfattende overvågningsaktiviteter for Ledger Recover-tjenesten. Selvom vi står ved vores forpligtelse til gennemsigtighed, anerkender vi også vigtigheden af ​​at bevare diskretion omkring detaljerne i de interne kontroller og overvågning af operationel sikkerhed.

Hos Ledger er sikkerhed vores prioritet. Det er kernen i vores løsninger, som er bygget på robuste kryptografiske protokoller som beskrevet i vores Ledger Recover hvidbog. Men vores arbejde fortsætter ud over skabelsen af ​​sikre systemer. Vi overvåger og vurderer konstant vores drift og leder efter eventuelle mistænkelige aktiviteter. Denne konstante årvågenhed styrker vores sikkerhedsposition og sikrer, at vi altid er klar til at reagere. 

Lad os udforske nogle eksempler på vores flerlagstilgang:

Overvågning af administratoraktiviteter: Vi håndhæver streng adgangskontrol for vores administratorer. Ikke kun kræver vi 2FA (tofaktorgodkendelse) for alle administrative forbindelser til vores infrastruktur, men vi kræver også validering af flere personer for adgang til administratorinfrastruktur på kritiske dele af systemet. Desuden logger og sporer vores systemer omhyggeligt enhver administrativ aktivitet. Disse logfiler krydsreferences automatisk med vores interne billetsystemer for at registrere eventuelle uplanlagte handlinger. Denne forsigtige sammenhæng gør os i stand til omgående at advare vores sikkerhedsteams om enhver usædvanlig eller mistænkelig adfærd, hvilket styrker vores operationelle sikkerhed.

Krydskontrol blandt sikkerhedskopieringsudbydere: Gennemsigtighed og ansvarlighed danner grundlaget for relationerne mellem backup-udbyderne, Ledger, EscrowTech og Coincover. Vi har etableret en realtidsudveksling af logfiler, der bruges til systemovervågning og sikkerhed. Dette muliggør krydsverifikation af aktiviteter. Hvis der opdages inkonsekvens, låses tjenesten øjeblikkeligt for at beskytte brugernes aktiver.

Overvågning af exceptionel udgivelsesaktivitet: De sjældne tilfælde af manuelle aktieudgivelser kontrolleres omhyggeligt gennem en proces med flere kvorum, som vi forklarede i det foregående afsnit. Efter udførelsen af ​​den ekstraordinære frigivelsesaktivitet fortsætter Ledger Recover-systemer med omfattende overvågning, herunder detaljeret logning og analyse af de involverede parter, driftstidspunkt og andre relevante detaljer. Denne proces, der involverer både eksekvering af flere kvorum og overvågning efter handling, sikrer, at den ekstraordinære frigivelse af aktier er stramt kontrolleret på alle stadier af beslutningsprocessen.

Udnyttelse af sikkerhedsinformation og hændelsesstyring (SIEM): SIEM-løsningen udgør en afgørende del af Ledger Recover-overvågningsstrategien. Denne dedikerede SIEM forbedrer evnen til at identificere og reagere på potentielle sikkerhedsproblemer i realtid. Den er finjusteret til at identificere en række kompromisindikatorer (IoC'er) baseret på klynge- og Ledger Recover-applikationslogfiler, takket være specifikke detektionsregler, der er specielt udviklet til Ledger Recover-tjenesten. Hvis en brugerdefineret IoC detekteres, er et svar automatisk og øjeblikkeligt - hele klyngen er låst, indtil en grundig analyse er udført. I Ledger Recover-tjenesten prioriteres fortrolighed frem for tilgængelighed af tjenesten for at sikre den største beskyttelse af brugernes aktiver.

I det dynamiske landskab af cybersikkerhed har vi lagt strategier og forberedt os på forskellige scenarier. Vores trusselsmodel tager højde for den usandsynlige situation, hvor flere infrastrukturadministratorer fra forskellige backup-udbydere kan blive kompromitteret. Med strenge sikkerhedsforanstaltninger og automatiske svar på plads, sigter Ledger Recover-tjenesten mod at sikre den fortsatte sikkerhed for brugernes aktiver selv under sådanne ekstraordinære omstændigheder. I det følgende afsnit vil vi skitsere de omfattende responsforanstaltninger, der er bygget til at tackle sådanne hypotetiske situationer.

Ledger Recover-specifik Incident Response

Med Ledger Recover-tjenesten er der bygget en Incident Response-strategi, som er designet i samarbejde med de tre backup-udbydere. En central del af denne strategi er automatiske sikkerhedsforanstaltninger, der øjeblikkeligt låser hele systemet ved detektering af mistænkelig aktivitet i enhver del af infrastrukturen. 

I det væsentlige er en "altid sikker, aldrig undskyld"-protokol blevet udviklet i Ledger Recover-tjenesten. Sikkerhed er førsteprioritet, og det er en forpligtelse, der aldrig vil blive gået på kompromis med. 

Selvom vi konstant stræber efter at give en problemfri brugeroplevelse til de næste 100 millioner mennesker i Web3, vil vi aldrig tøve med at aktivere disse sikkerhedsforanstaltninger, effektivt at låse hele Ledger Recover-tjenesten ned, hvis der opstår en potentiel trussel. I vores mission om at beskytte er valget mellem at køre en potentielt kompromitteret tjeneste og at sikre den ultimative sikkerhed klart – vi vælger sikkerhed.

Konklusion

Her er vi ved slutningen af ​​Operational Security-delen af ​​denne serie. I denne del har vi forsøgt at besvare enhver bekymring, du måtte have med hensyn til, hvordan uindtageligheden af ​​Ledger Recover-systemets sikkerhedsforanstaltninger er sikret. Vi talte om infrastrukturen, adskillelsen af ​​opgaver, styring og overvågning og endelig Incident Response-strategien. 

Endnu en gang tak fordi du læste med hele vejen op til dette punkt! Du bør nu have en omfattende forståelse af Ledger Recovers operationelle sikkerhed. Den sidste del af denne blogindlægsserie vil handle om de sidste sikkerhedsproblemer, vi havde, og mere præcist: hvordan styrede vi vores interne og eksterne sikkerhedsrevisioner for at garantere det maksimale sikkerhedsniveau for vores brugere? Bliv hængende! 

Tidsstempel:

Mere fra Ledger