Del 5: Genesis of Ledger Recover - Operasjonell sikkerhet | Ledger

Del 5: Genesis of Ledger Recover – Operasjonell sikkerhet | Ledger

Så langt har vi vist i del 1 og 2 hvordan Ledger Recover deler frøet ditt i aksjer og sender disse aksjene sikkert til venner pålitelige sikkerhetskopieringsleverandører. I del 3 har vi vist hvordan det er lagrer (og gjenoppretter) trygt andelene av frøet ditt, beskyttet av maskinvarekryptering, knyttet til din identitet og diversifisert. I del 4 har vi utforsket hvordan Ledger Recover klarer å gi tilgang til sikkerhetskopien bare til deg og deg.

Det er nå på tide å se nærmere på hvordan vi sikrer maksimal sikkerhet på operativt nivå. På et øyeblikk oppnås driftssikkerhet ved å:

  • Herding av infrastrukturen som ligger til grunn for Ledger Recover,
  • Å bruke oppgaveseparasjon til de forskjellige operatørene av Ledger Recover,
  • Overvåking av kritiske komponenter og operasjoner,
  • Implementering av en gjenopprettingsspesifikk hendelsesrespons.

La oss dykke ned i detaljene om hva hver av disse elementene betyr.

Herding av infrastruktur

Herding av infrastruktur kommer i mange former. Det er en 360°-øvelse som involverer et bredt spekter av aktiviteter drevet av en grundig analyse av sikkerhetsrisikoer. Det starter vanligvis med å opprettholde en katalog over angrepsscenarier som kan føre til sikkerhetsproblemer (som datalekkasjer, etterligning av klienter som fører til uautorisert gjenoppretting av delinger, ikke-responsive systemer og tjenesteavbrudd). Forebygging av disse problemene på operasjonelt nivå er organisert rundt aktiviteter som ressursisolering, systemtilgangsregulering, nettverkstrafikkkontroll, sårbarhetshåndtering og mange flere.

Del 5: Genesis of Ledger Recover - Operasjonell sikkerhet | Ledger PlatoBlockchain Data Intelligence. Vertikalt søk. Ai.
Del 5: Genesis of Ledger Recover - Operasjonell sikkerhet | Ledger

Her er en oversikt over våre viktigste tiltak for å herde Ledger Recovers infrastruktur:

Tjenestetilgjengelighet

Infrastrukturen er utformet slik at det er intet enkelt feilpunkt (NSPOF), noe som betyr at systemet er motstandsdyktig mot feil på en hvilken som helst komponent. La oss ta følgende eksempel: datasentrene våre betjenes av to uavhengige Internett-leverandører (ISP) i to motsatte ender av bygningen. Dersom fiberen blir skadet på grunn av pågående byggearbeid i en del av bygget, vil data rett og slett bli rutet gjennom den andre ISPen. Avbruddsfritt vedlikehold er enda en fordel som øker tilgjengeligheten. Gitt at det er minst to forekomster av alle programvarekomponenter av Ledger Recover, kan vi rekonfigurere systemet til å bruke bare forekomst A mens vi erstatter/oppgraderer/fikser forekomst B.

Begrenset administratortilgang til Ledger Recover-applikasjoner

Bare en redusert sett med brukere gis administratortilgang til ressursene som er dedikert til Ledger Recover. Jo kortere listen over brukere er, jo mer kan vi redusere risikoen for at innsidetrusler får administratortilgang.

Sikre fysiske datasentre

Backup-leverandørenes HSM-er er vert for geografisk overflødig fysiske datasentre, beskyttet mot fysiske og virtuelle trusler ved hjelp av sikkerhetsteknikker og prosedyrer i bransjeklasse. Nivået på fysisk beskyttelse sikrer at ingen uautorisert person tilfeldig kan gå bort med en HSM. Å stole på datasentre på tvers av flere nettsteder betyr at hvis ett sted opplever et problem, kan et annet sted ta over, og uavbrutt tjenestetilgjengelighet. Sist men ikke minst gir det oss å administrere våre egne HSM-er kontroll over hvem som har tilgang til dem og hvilken kode som er distribuert på dem.

Isolering av Ledger Recover-ressurser

Alle Ledger Recover-ressurser er isolert fra alle andre ressurser innen Ledger Recovers tjenesteleverandører, inkludert innen Coincover og Ledger. Denne isolasjonen er nødvendig for å sikre at vi kan inneholde potensielle angrep fra én nettverksdel rettet mot å utnytte ressursene til andre nettverksdeler.

Sikkerhet på kodenivå sikret via flere søyler
  • Vi bruker kodeskannere for å hjelpe oss med å identifisere og adressere sårbarheter tidlig, og hindre dem i å komme inn i produksjonen.
  • Kode is anmeldt og godkjent by et team uavhengig av den som utvikler Ledger Recover. Denne separasjonen er nok et tiltak for å forbedre den generelle kodekvaliteten ved å fange opp logiske feil som kan føre til sikkerhetsproblemer.
  • Koden til kritiske moduler av Ledger Recover er signert med en kryptografisk signatur. Signaturen er delvis generert basert på kodens innhold, og forhindrer distribusjon av manipulert kode ved å sammenligne signaturen med dens forventede verdi. Denne sikkerhetskontrollen utføres før koden kjøres.
Nettverkstrafikkkontroll

Nettverkstrafikk er tett kontrollert via policyer som definerer regler for trafikkflyt for alle 3 sikkerhetskopieringsleverandører. Av definere regler for tillatt og nektet trafikk, begrenser vi angrepsflaten og reduserer risikoen for uautorisert tilgang. Begrensning av kommunikasjon mellom individuelle tjenester sikrer også at angriperens sidebevegelse er begrenset, selv om en komponent er kompromittert. I tillegg bruker vi gjensidig TLS (mTLS)-autentisering for å forhindre Man-in-the-Middle (MiM)-angrep. Ved å verifisere identiteten til begge parter med sertifikater, sikrer gjensidig TLS det bare klarerte enheter kan opprette en sikker tilkobling.

Nøkkelrotasjon

kryptering nøkler (brukes for eksempel til å kryptere data eller kommunikasjon) er endres regelmessig i tråd med beste praksis for kryptografi. Fordelen med dette er at hvis en nøkkel blir kompromittert, vil den skaden er begrenset til tiden mellom rotasjoner og til dataene kryptert med den gamle nøkkelen.

Utgående trafikksikkerhet

Utgående trafikk er begrenset til kun kjente domener og IP-adresser (sikkerhetskopieringsleverandører, tjenesteleverandører). Begrensning og overvåking av utgående trafikk er en måte å vær oppmerksom på potensielle datalekkasjer. Hvis volumet av utgående datastrømmer er høyere enn forventet, kan en ondsinnet aktør trekke ut sensitive data fra Ledger Recover-systemet i betydelig skala. 

Inngående trafikksikkerhet

Innkommende trafikk er beskyttet av en kombinasjon av anti-DDoS, webapplikasjonsfiltrering (WAF) og IP-filtreringsteknikker. Distribuerte denial-of-service-angrep (DDoS) skader ved å overfylle målsystemet med forespørsler. Begrensning av antall innkommende forespørsler er et velkjent tiltak mot slike angrep. Nå handler ikke alle angrep om kvantitet, noen av dem handler om kvalitet. Det er her WAF kommer inn i bildet. WAF ser på innkommende forespørsler og inspiserer deres tiltenkte oppførsel: hvis forespørselen tar sikte på å få uautorisert tilgang eller manipulere data, blokkerer filteret forespørselen. Til slutt bruker IP-filtrering den doble teknikken til a) hvitlisting, det vil si å tillate trafikk kun fra bestemte IP-adresser eller områder, og b) svartelisting, det vil si blokkering trafikk fra kjente angriper-IP-er.       

Sikkerhetsstyring

Komponentene i Ledger Recover-infrastrukturen er kontinuerlig og systematisk skannet for kjente sårbarheter og feilkonfigurasjoner, og patcher/oppdateringer brukes regelmessig. Dette hjelper svaret på nye typer trusler etter hvert som de dukker opp og holder sikkerhetstiltakene oppdatert og i verdensklasse.

Separasjon av plikter

Separasjon av oppgaver er kjernen i sikkerhetsstrategien til Ledger Recover. 

Arbeidsfordelingen mellom de ulike Leverandører av sikkerhetskopiering (del 3) og IDV-leverandørs (del 4) har blitt beskrevet i de tidligere innleggene. Du husker kanskje at det er:

  • 3 andeler av Secret Recovery Phrase administrert av 3 uavhengige sikkerhetskopieringsleverandører (med databasediversifisering på toppen for å forhindre samarbeid)
  • 2 uavhengige identitetsvalidatorer (IDV-leverandører)

På infrastrukturnivå, separasjon av oppgaver blir brukt mellom de ulike rollene involvert i utvikling og drift av Ledger Recover.

I tillegg kombinerer vi oppgaveseparasjonen med «minste privilegium»-prinsippet. "Minste privilegium" er prinsippet som brukes på systemoperatører og administratorer: de får rett til å gjøre bare det de trenger å gjøre, for å sikre at de får det laveste nivået av tillatelse som kreves for å utføre pliktene sine. 

Så når "minste privilegium" er kombinert med "atskillelse av oppgaver", ulike administratorroller er tildelt ulike personer slik at ingen enkeltperson kan skade/kompromittere konfidensialiteten eller integriteten til noen systemkomponent. For eksempel har ikke utviklere av Ledger Recover-kode tilgang til systemet som kjører koden de skrev.

Del 5: Genesis of Ledger Recover - Operasjonell sikkerhet | Ledger PlatoBlockchain Data Intelligence. Vertikalt søk. Ai.
Del 5: Genesis of Ledger Recover - Operasjonell sikkerhet | Ledger
Styring: Quorums

I likhet med Blockchains sine konsensusmekanismer som garanterer integritet og sikkerhet ved å la flere aktører verifisere blokker, har vi vedtatt et quorum i Ledger Recover-systemet for å forbedre vår operasjonelle sikkerhet.

Til tross for våre robuste bakgrunnssjekker for våre ansatte, gjenstår det faktum at mennesker kan være et svakt ledd i ethvert system, og kryptosfæren er intet unntak. Høyprofilerte sikkerhetshendelser, for eksempel Mt. Gox hack fra 2014, demonstrere hvordan enkeltpersoner kan utnyttes eller føre til sikkerhetsbrudd. Folk kan bli påvirket eller tvunget gjennom ulike motivasjoner – penger, ideologi, tvang, ego (aka, MICE(S)) – noe som gjør at selv de strengeste bakgrunnssjekkene ikke er helt idiotsikre.

For å redusere slike risikoer bruker vi et system basert på konseptet om et beslutningsdyktighet. Dette rammeverket krever konsensus fra minst tre autoriserte personer fra forskjellige team eller avdelinger innen backupleverandører før noen vesentlige beslutninger eller kritiske handlinger kan tas. 

Det nøyaktige antallet personer involvert i våre forskjellige quorumer forblir ukjent av sikkerhetsmessige årsaker. Likevel forbedrer dens eksistens betydelig vår operasjonelle sikkerhet ved å utvanne den potensielle innflytelsen til et enkelt kompromittert individ.

Her er noen av aktivitetene der vi bruker quorumer:

1. Generering av de private nøklene for Ledger Recover HSM-er: Denne kritiske operasjonen ivaretas av uavhengige quorumer i hver enhet – Coincover, EscrowTech og Ledger. Hvert medlem av disse distinkte quorumene må være til stede for å generere private nøkler i sine respektive HSM-er. Hvert quorumsmedlem har tilgang til en sikkerhetskopinøkkel, som er avgjørende for å gjenopprette og gjenopprette deres HSM-hemmeligheter om nødvendig. Denne strukturen beskytter ikke bare mot risikoen for at noen har utilbørlig innflytelse over en av de tre sikkerhetskopieringsleverandørene, men forbedrer også den generelle systemintegriteten ettersom hvert quorum opererer uavhengig og er uvitende om hverandres spesifikasjoner.

Del 5: Genesis of Ledger Recover - Operasjonell sikkerhet | Ledger PlatoBlockchain Data Intelligence. Vertikalt søk. Ai.
Del 5: Genesis of Ledger Recover - Operasjonell sikkerhet | Ledger
Husk at selv et fullstendig kompromittert beslutningsdyktighet ikke kan sette brukereiendeler i fare. Husk fra blogginnlegg 2: Hver leverandør av sikkerhetskopiering håndterer bare en enkelt deling. Uten alle nødvendige delinger er det umulig å rekonstruere en brukers frø. 

Dessuten kan ikke uttak av den private nøkkelen til HSM, som er nødvendig for å dechiffrere eksisterende aksjer, gjøres med quorumets reservenøkler. Sikkerhetskopileverandørens quorumsmedlemmer vil bare kunne gjenopprette og gjenskape en ny HSM.

2. Å bestemme seg for en eksepsjonell utgivelse av en kundes andel: Spesifikke, om enn sjeldne, situasjoner kan kreve en eksepsjonell frigivelse av en kundes andel. Disse kan skyldes identitetsbekreftelsesfeil (navneendring, fysisk vansiring osv.), eller hvis våre ikke-avslørte sikkerhetstiltak feilaktig blokkerer en enhet. Når en slik situasjon oppstår, kommer et beslutningsdyktighet bestående av flere personer fra backupleverandørene sammen. Denne prosedyren, som krever bred konsensus, sikrer at beslutninger ikke tas forhastet eller ensidig, og dermed øker kundenes sikkerhet. Hvert medlem av quorumet bruker sin Ledger Nano-enhet (med sin egen pinne) for å godkjenne utgivelsen, og legger til et nytt lag med sikkerhet mot mulig samarbeid eller individuelle feil.

3. Signering av HSM-firmware-kodeoppdatering: Før vi distribuerer en ny fastvareoppdatering til HSM-ene, gjennomfører produktsikkerhetsteamet vårt, Ledger Donjon, en omfattende gjennomgangsprosess. Som en del av fastvarequorumet, sikrer Ledger Donjon at ingen bakdører eller ondsinnet kode har blitt introdusert av en ondsinnet innsider eller en kompromittert utviklingspipeline via forsyningskjedeangrep. På den måten opprettholder de integriteten og sikkerheten til fastvareoppdateringen.

4. Signing Ledger-enheter (Nano & Stax) fastvarekodeoppdatering: På samme måte som fastvaren for HSM-ene, går oppdateringer til fastvaren til Ledger-enheten vår gjennom en streng gjennomgangsprosess og krever quorumsgodkjenning før de foreslås til våre brukere via Ledger Live.

Avslutningsvis er quorumer en integrert del av Ledger Recovers sikkerhetsarkitektur. De spiller en viktig rolle i å befeste forsvar mot interne useriøse trusler og samarbeid under vitale operasjoner. Ved å utnytte den førsteklasses sikkerheten til Ledger-enheter og -tjenester bidrar quorumer til å sikre tillit og beskytte brukernes digitale eiendeler mot ondsinnede innsidere.

Overvåking av kritiske komponenter og operasjoner

Når vi fordyper oss i dette kapittelet, er det viktig å merke seg at vi av sikkerhetsgrunner bare avslører en undergruppe av de omfattende overvåkingsaktivitetene for Ledger Recover-tjenesten. Selv om vi står ved vår forpliktelse til åpenhet, anerkjenner vi også viktigheten av å opprettholde diskresjon rundt detaljene i de interne kontrollene og overvåking av operasjonell sikkerhet.

Hos Ledger er sikkerhet vår prioritet. Det er kjernen i våre løsninger, som er bygget på robuste kryptografiske protokoller som beskrevet i vår Hvitbok for Ledger Recover. Men arbeidet vårt fortsetter utover etableringen av sikre systemer. Vi overvåker og vurderer kontinuerlig driften vår og ser etter mistenkelige aktiviteter. Denne kontinuerlige årvåkenheten styrker vår sikkerhetsholdning, og sikrer at vi alltid er klare til å svare. 

La oss utforske noen eksempler på vår flerlags-tilnærming:

Overvåking av administratoraktiviteter: Vi håndhever streng tilgangskontroll for administratorene våre. Ikke bare krever vi 2FA (tofaktorautentisering) for alle administrative tilkoblinger til infrastrukturen vår, men vi gir også mandat til flere personers validering for tilgang til administratorinfrastruktur på kritiske deler av systemet. Videre logger og sporer systemene våre omhyggelig hver administrativ aktivitet. Disse loggene kryssreferanser automatisk med våre interne billettsystemer for å oppdage eventuelle ikke-planlagte handlinger. Denne forsiktige sammenhengen gjør det mulig for oss å umiddelbart varsle sikkerhetsteamene våre om uvanlig eller mistenkelig oppførsel, noe som forsterker vår operasjonelle sikkerhet.

Krysskontroll blant sikkerhetskopieringsleverandører: Åpenhet og ansvarlighet danner grunnlaget for relasjonene mellom backupleverandørene, Ledger, EscrowTech og Coincover. Vi har etablert en sanntidsutveksling av logger som brukes til systemovervåking og sikkerhet. Dette muliggjør kryssverifisering av aktiviteter. Hvis det oppdages inkonsekvens, låses tjenesten umiddelbart for å beskytte brukernes eiendeler.

Overvåke eksepsjonell utgivelsesaktivitet: De sjeldne tilfellene av manuelle aksjeutgivelser kontrolleres nøye gjennom en prosess med flere quorumer, som vi forklarte i forrige avsnitt. Etter utførelsen av den eksepsjonelle utgivelsesaktiviteten, fortsetter Ledger Recover-systemene med omfattende overvåking, inkludert detaljert logging og analyse av involverte parter, driftstidspunkt og andre relevante detaljer. Denne prosessen, som involverer både utførelse av flere kvorum og overvåking etter handling, sikrer at den eksepsjonelle frigivelsen av aksjer er tett kontrollert i alle stadier av beslutningsprosessen.

Utnytte sikkerhetsinformasjon og hendelsesadministrasjon (SIEM): SIEM-løsningen utgjør en avgjørende del av overvåkingsstrategien Ledger Recover. Denne dedikerte SIEM forbedrer muligheten til å identifisere og svare på potensielle sikkerhetsproblemer i sanntid. Den er finjustert for å identifisere en rekke kompromissindikatorer (IoCs) basert på cluster- og Ledger Recover-applikasjonslogger, takket være spesifikke deteksjonsregler spesielt utviklet for Ledger Recover-tjenesten. Hvis en tilpasset IoC oppdages, er en respons automatisk og umiddelbar – hele klyngen er låst inntil en grundig analyse er utført. I Ledger Recover-tjenesten er konfidensialitet prioritert fremfor tilgjengeligheten av tjenesten for å sikre best mulig beskyttelse av brukernes eiendeler.

I det dynamiske landskapet av cybersikkerhet har vi lagt strategier og forberedt oss på ulike scenarier. Trusselmodellen vår tar hensyn til den usannsynlige situasjonen der flere infrastrukturadministratorer fra forskjellige sikkerhetskopieringsleverandører kan bli kompromittert. Med strenge sikkerhetstiltak og automatiske svar på plass, har Ledger Recover-tjenesten som mål å sikre fortsatt sikkerhet for brukernes eiendeler selv under slike ekstraordinære omstendigheter. I den følgende delen vil vi skissere de omfattende responstiltakene som er laget for å takle slike hypotetiske situasjoner.

Reskontrogjenopprettingsspesifikk hendelsesrespons

Med Ledger Recover-tjenesten er det bygget en Incident Response-strategi, utviklet i samarbeid med de tre backupleverandørene. En sentral del av denne strategien er automatiske sikkerhetstiltak som umiddelbart låser hele systemet ved oppdagelse av mistenkelig aktivitet i noen del av infrastrukturen. 

I hovedsak har en "alltid sikker, aldri beklager"-protokoll blitt utviklet i Ledger Recover-tjenesten. Sikkerhet er førsteprioritet, og det er en forpliktelse som aldri vil bli kompromisset med. 

Selv om vi kontinuerlig streber etter å gi en sømløs brukeropplevelse til de neste 100 millioner menneskene i Web3, vil vi aldri nøle med å aktivere disse sikkerhetstiltakene, effektivt låse ned hele Ledger Recover-tjenesten, hvis en potensiell trussel oppstår. I vårt oppdrag om å beskytte er valget mellom å kjøre en potensielt kompromittert tjeneste og å sikre ultimat sikkerhet klart – vi velger sikkerhet.

konklusjonen

Her er vi ved slutten av Operasjonell sikkerhet-delen av denne serien. I denne delen har vi forsøkt å svare på eventuelle bekymringer du måtte ha angående hvordan ugjennomtrengeligheten til Ledger Recover-systemets sikkerhetstiltak er sikret. Vi snakket om infrastrukturen, oppgavedeling, styring og overvåking, og til slutt Incident Response-strategien. 

Takk nok en gang for at du leste helt frem til dette punktet! Du bør nå ha en omfattende forståelse av Ledger Recovers operasjonelle sikkerhet. Den siste delen av denne bloggpostserien vil handle om de siste sikkerhetsbekymringene vi hadde, og mer presist: hvordan administrerte vi våre interne og eksterne sikkerhetsrevisjoner for å garantere maksimalt sikkerhetsnivå for brukerne våre? Følg med! 

Tidstempel:

Mer fra Ledger