ONDERZOEK
Het onderzoek achter het ontwerp.
Aantoonbare data-integriteit betekent dat u ons nooit op ons woord hoeft te geloven: elke garantie wordt als eigenschap geformuleerd en vervolgens afgeleid, zodat uw beoordelaar haar kan volgen, aanvechten en iets anders kan aftekenen dan een verkooppresentatie. Op deze pagina worden die documenten gepubliceerd, en hier verschijnen ook de documenten over wat wij hierna bouwen. De technische documentatie staat al online en behandelt hetzelfde ontwerp in een andere vorm.
DataPrism paper
Het ontwerp van het systeem van begin tot eind, en de formele garanties achter de drie eigenschappen.
WAT HET AANTOONT
Dat de eigenschappen gevolgen zijn van het ontwerp, geen instellingen. U kunt elke afleiding volgen tot aan de aanname waarop ze rust, en houdt een van die aannames in uw omgeving geen stand, dan ziet u precies waar het betoog ophoudt te gelden.
VOOR WIE HET IS
Voor de architect of securitybeoordelaar die een opslagontwerp moet aftekenen en later verantwoording aflegt voor die handtekening. Voor het verhaal in plaats van de afleiding, lees hoe het ontwerp een product wordt.
Verschijnt binnenkort
Paper over betrouwbaarheid
De betrouwbaarheidsmodellen achter de spreiding: hoe redundantie over onafhankelijke providers zich vertaalt in storingen en weigeringen die te overleven zijn, tot de redundantiedrempel die u kiest. De rekenkunde van duurzaamheid, uitgeschreven om gecontroleerd te worden, niet om op vertrouwen te worden aangenomen.
WAT HET AANTOONT
Dat voortbestaan bij uitval wordt berekend, niet gehoopt: vul uw eigen aantal providers en uw eigen drempel in de modellen in, en u krijgt de combinaties van storingen en weigeringen die de spreiding opvangt, en die ene waar het ophoudt.
VOOR WIE HET IS
Voor de engineer die moet antwoorden wat er gebeurt als een provider uitvalt, met een model in plaats van een bijvoeglijk naamwoord.
Verschijnt binnenkort
Overzicht van de beveiligingsarchitectuur
Het dreigingsmodel in zijn geheel: wat elke actor kan zien, waarop elke garantie rust, en de cryptografische keuzes daarachter.
WAT HET AANTOONT
Wie wat kan lezen, onder welke voorwaarden: provider, operator, autoriteit, aanvaller, elk doorgelopen tegen de architectuur. Het meeste van wat een securityvragenlijst vraagt is rechtstreeks uit dit document te beantwoorden.
VOOR WIE HET IS
Voor de CISO of security engineer die due diligence doet vóór een pilot, en liever leest dan een gesprek inplant.
Verschijnt binnenkort
WAT DE PAPERS BEHANDELEN
Wat aantoonbare data-integriteit formeel betekent.
FORMELE GARANTIES
De eigenschappen geformuleerd en afgeleid, zodat u elk daarvan tegen uw eigen dreigingsmodel kunt toetsen.
BETROUWBAARHEIDSMODELLEN
Wat overleeft wanneer providers uitvallen of weigeren, en waar de grens ligt, zodat u uw redundantiedrempel op bewijs baseert.
ARCHITECTUUR
De volledige architectuur, van client tot register, met de vertrouwensaanname van elke stap uitgeschreven.
GEFORMULEERDE GARANTIES
Vier zinnen waarvan wij verwachten dat ze ons worden voorgehouden.
Deze beweringen doen wij op de hele site. De eerste drie zijn geformuleerde eigenschappen met een afleiding erachter in de papers. De vierde is wat daar in de praktijk uit volgt. Citeer ze in uw securityreview, en houd ons eraan.
-
VERTROUWELIJKHEID
De versleuteling gebeurt vóór de upload. Niemand kan uw data lezen, wij ook niet.
-
BESCHIKBAARHEID
Bestanden worden met redundantie gespreid over onafhankelijke providers. De storing van één provider kan uw data niet onbereikbaar maken.
-
INTEGRITEIT
Elk fragment is content-addressed. Manipulatie is van begin tot eind detecteerbaar.
-
DWANG
Een operator die een verzoek krijgt, kan alleen onvolledige fragmenten ciphertext overleggen. De sleutel wordt aan uw kant afgeleid en nergens opgeslagen, ook hier niet.
WAAROM WIJ PUBLICEREN
Wij worden liever gecontroleerd dan geloofd.
Infrastructuur die om uw gevoeligste data vraagt, hoort niet op bijvoeglijke naamwoorden te worden beoordeeld, en u hoort niet op goed vertrouwen af te tekenen. Door het ontwerp te publiceren, met zijn garanties geformuleerd en afgeleid, wordt ons securityverhaal iets dat uw beoordelaar kan aanvallen: lees de beweringen, volg de afleidingen, zoek het gat. Uw due diligence krijgt een document in plaats van een vergadering, en vindt u een gat, dan horen wij het liever eerder dan wie ook.
De papers zijn één laag van een controleerbare stack: het dreigingsmodel in gewone taal heeft hierboven zijn eigen overzicht, en de SDK voor client-side versleuteling is openbaar gedocumenteerd. Elk document hierboven linkt naar zijn PDF zodra dat document is gepubliceerd.
Deze pagina is een plek, geen momentopname van één release. De documenten hierboven behandelen het systeem zoals het er vandaag staat. Naarmate het ontwerp mogelijkheden krijgt, worden de papers die de garanties van die mogelijkheden formuleren en afleiden hier op dezelfde manier gepubliceerd, onder dezelfde regel: eerst de bewering, dan de afleiding erachter.
Gebouwd op onderzoek dat wij publiceren.
De docs laten zien hoe het ontwerp een SDK wordt die uw engineers regel voor regel kunnen lezen.