Model bezpieczeństwa: serwer przechowuje tylko szyfrogramy

Crunu szyfruje zawartość każdego środowiska w twojej przeglądarce albo w agencie crunu, zanim cokolwiek zostanie wysłane. Serwer przechowuje zaszyfrowane dane, klucze publiczne i podpisane rekordy, a w żadnym momencie protokołu nie ma klucza, który mógłby je odszyfrować.

Na app.crunu.com ten serwer prowadzi Crunu. Jeśli hostujesz Crunu samodzielnie, prowadzisz go ty. W obu przypadkach serwer nie może odczytać twoich wartości. Crunu jest we wczesnym dostępie, więc opisujemy tylko to, co robi obecne wydanie, i aktualizujemy tę stronę, gdy to się zmienia.

W skrócie

• Twoje środowiska są szyfrowane na twoich urządzeniach. Serwer przechowuje tylko zaszyfrowane dane i nie ma klucza, by je odczytać.
• Twoje hasło i Secret Key nigdy nie opuszczają urządzenia, więc skradziona baza danych nie pomoże nikomu ich odgadnąć.
• Każde środowisko ma własny klucz. Ludzie, maszyny i tokeny CI dostają tylko te środowiska, do których mają dostęp.
• Listy dostępu i wersje są podpisane, więc serwer nie może niepostrzeżenie dopisać siebie jako odbiorcy ani zmienić twoich danych.
• Serwer nadal widzi metadane: nazwy, adresy e-mail, dziennik audytu i to, kiedy zapisano każdą wersję.
• Główne pozostałe ryzyko to zmodyfikowana strona internetowa. Znane ograniczenia opisują je razem z każdym innym znanym nam ograniczeniem.
• Nie publikujemy raportu SOC 2 ani zewnętrznego audytu. Chcesz zgłosić problem? Napisz na security@crunu.com.

Jak sekret wędruje, krok po kroku

Prześledź STRIPE_SECRET_KEY od chwili, gdy Priya go zapisuje, do programów, które go odczytują.

1. Przeglądarka Priyi szyfruje i podpisuje. Jej hasło i Secret Key – 26 losowych znaków utworzonych na jej urządzeniu – łączą się w klucz konta, a żadne z nich nigdy nie jest wysyłane. Przy zapisie przeglądarka szyfruje całą nową wersję środowiska, każdy plik i każdą zmienną, jako jeden rekord kluczem tego środowiska (AES-256-GCM). Dopełnia rekord do pełnych bloków 4 KB, żeby nie było widać dokładnego rozmiaru, i podpisuje wersję jako Priya (Ed25519).
2. Serwer przechowuje to, czego nie może otworzyć. Przechowuje jeden zaszyfrowany rekord na wersję, a nie na każdą wartość, razem z podpisaną listą dostępu, która mówi, kto może go odczytać. Decyduje, komu przekazać zaszyfrowane dane, ale nie ma klucza, by je odszyfrować.
3. Osoba z zespołu dostaje tylko przyznane środowiska. Jonas dostaje klucze środowisk development i staging, każdy zaszyfrowany jego własnym kluczem publicznym (X25519). Production nie ma na jego liście dostępu, więc nigdy nie dostaje jego klucza. Jego przeglądarka przed odszyfrowaniem sprawdza każdy podpis i numer wersji.
4. Serwer dostaje swoje środowisko w ten sam sposób. Agent na api-prod-1 dostaje klucz production zaszyfrowany dla tej maszyny, sprawdza, co przysłał serwer, i trzyma odszyfrowane środowisko w pamięci. Twój program dostaje je przez crunu run albo jako pliki tam, gdzie o to poprosisz poleceniem crunu pull.
5. Zadanie CI dostaje dokładnie swoją część. Token usługowy dla GitHub Actions może odczytać tylko web-app / staging. Z powiązaniem z CI (OIDC) działa tylko z wybranego repozytorium i gałęzi.

Na app.crunu.com serwer działa na Cloudflare. Strona Podprocesorzy wymienia każdą firmę, która przetwarza dane dla usługi, i to, co każda z nich może zobaczyć.

W dokumentacji: Jak działa szyfrowanie

Klucze i algorytmy

Crunu korzysta ze standardowych elementów: AES-256-GCM do szyfrowania, X25519 do szyfrowania kluczy dla odbiorcy, Ed25519 do podpisów oraz HKDF-SHA256 i PBKDF2-SHA256 do wyprowadzania kluczy. Przeglądarka używa wbudowanego WebCrypto, a agent – biblioteki standardowej Go. Oba są testowane na tych samych wektorach testowych.

Jeśli wycieknie kopia bazy danych, odgadnięcie z niej twojego hasła się nie uda: każda próba wymaga też twojego Secret Key, którego nigdy nie było na serwerze, więc sprawdzenie jednej próby oznacza przeszukanie około 2¹²⁸ możliwości. Tokeny są przechowywane tylko jako skróty z kluczem.

W dokumentacji: Emergency Kit i Secret Key · Kod odzyskiwania

Każde środowisko jest szyfrowane osobno

• Organizacje rozdzielają ich własne klucze. Jeden serwer może obsługiwać wiele organizacji. Każda ma własne klucze podpisu i odzyskiwania, a jej klucze środowisk są szyfrowane tylko dla członków i maszyn, które ta organizacja certyfikowała.
• Dostęp do development nie otwiera production. Każde środowisko ma własny klucz, a ktoś bez klucza production nie odczyta production.
• Specific files to naprawdę wybrane pliki. Osoba z tą rolą albo maszyna ustawiona na Selected files dostaje zaszyfrowaną kopię tylko wybranych plików.
• Operatorzy konfigurują maszyny, nie widząc wartości. Nie mają żadnego klucza środowiska. Dostęp każdej maszyny zatwierdza osoba, która ma klucz.
• Reguły sieciowe ograniczają, dokąd trafia zawartość. Środowisko może być wydawane tylko dozwolonym zakresom IP – ludziom, maszynom i tokenom tak samo. Złagodzenie reguły czeka 15 minut z alertem, chyba że podpisze je drugi administrator. Zaostrzenie działa od razu. Tę regułę egzekwuje serwer, a nie szyfrowanie.

W dokumentacji: Role w organizacjach i środowiskach · Reguły sieciowe

Co serwer widzi, a czego nie

Serwer, który nie może odczytać wartości, i tak potrzebuje kilku informacji: komu dostarczyć zaszyfrowane dane i co zapisać w dzienniku audytu. Oto pełna lista.

Czytelne dla serwera

• Nazwy organizacji, projektów, środowisk, maszyn, tokenów usługowych, profili dostępu i list sieci
• Imiona, nazwiska i adresy e-mail członków oraz adresy, na które idą zaproszenia
• Kto ma jaką rolę w którym środowisku – z podpisanej listy dostępu
• Dla każdej wersji: jej numer, kto ją zapisał, kiedy oraz jej rozmiar zaokrąglony w górę do wielokrotności 4 KB
• Którą wersję otrzymała każda osoba, maszyna i każdy token, kiedy i z jakiego adresu IP
• Dziennik audytu, twoje urządzenia i sesje oraz adresy IP, z których korzystają
• Twoje reguły sieciowe: dozwolone zakresy IP
• Sekret twojej aplikacji uwierzytelniającej, jeśli jej używasz. Serwer sprawdza twoje kody, więc przechowuje ten sekret zaszyfrowany własnym kluczem.

Tylko zaszyfrowane dane

• Wszystko w środowisku: nazwy i wartości zmiennych, nazwy plików, ścieżki, zawartość i notatki. Każda wersja to jeden zaszyfrowany rekord całego środowiska, więc serwer nie widzi poszczególnych zmiennych ani tego, która się zmieniła.
• Pliki wysyłane przez linki dostępu
• Klucze prywatne kont i organizacji

W ogóle nie trafia na serwer

• Twoje hasło i twój Secret Key
• Twój kod odzyskiwania. Serwer ma kopię klucza twojego konta, którą może odszyfrować tylko ten kod.
• Klucze prywatne maszyn, które powstają na maszynie i na niej zostają
• Klucz w linku dostępu, który jest po znaku #, a tej części przeglądarki nie wysyłają
• Same tokeny usługowe. Serwer zna tylko ich klucze publiczne.

To właśnie rozumiemy przez serwer, który nie może odczytać wartości: widzi kto i kiedy, ale nic wewnątrz twoich środowisk. Na app.crunu.com lista czytelnych danych to dokładnie to, co widzi Crunu, a Polityka prywatności mówi, jak długo je przechowujemy. Nie umieszczaj sekretów w nazwach: projekt nazwany od nieogłoszonej transakcji zdradza serwerowi tę transakcję, choć każda wartość w środku pozostaje zaszyfrowana.

W dokumentacji: Co widzi serwer

Kto może odczytać twoje sekrety

• Osoby, którym dasz dostęp. Członkowie zespołu dostają tylko przyznane środowiska. Ukrywanie wartości w aplikacji to sposób wyświetlania: kto może odszyfrować wartość, może ją skopiować.
• Właściciele i administratorzy. Mają klucz odzyskiwania organizacji, więc mogą otworzyć każde wspólne środowisko. Mogą też otwierać osobiste środowiska członków, dopóki w organizacji jest włączone odzyskiwanie środowisk osobistych, co jest ustawieniem domyślnym.
• Maszyny i CI. Każda maszyna i każdy token odczytuje tylko to, co dostał. Kody rejestracji domyślnie działają 15 minut i tracą ważność przy pierwszym użyciu, a maszynę zatwierdzasz dopiero po porównaniu odcisku klucza, który wypisuje na niej crunu enroll. Maszyna, której odebrano dostęp, usuwa swoje środowiska w ciągu kilku minut, jeśli jest online.
• Nie pracownicy Crunu. Na app.crunu.com serwer prowadzi Crunu, a serwer nie ma klucza. Widzimy metadane opisane wyżej. Dotarcie do twoich wartości wymagałoby zmiany kodu, który działa na twoim urządzeniu, na przykład zmodyfikowanej strony internetowej. Znane ograniczenia wyjaśniają to ryzyko.
• Każdy, kto próbuje dostać się do konta. Logowanie dopuszcza 10 nieudanych prób na adres IP i 5 na konto w ciągu 15 minut, a nieznany e-mail i błędne hasło dostają tę samą odpowiedź. Nowe urządzenie wymaga drugiego składnika – aplikacji uwierzytelniającej lub klucza dostępu – gdy go włączysz. Sesje kończą się po 12 godzinach bezczynności i najpóźniej po 7 dniach, a skradziona sesja nie pozwala zmienić hasła, Secret Key ani kluczy konta.

W dokumentacji: Maszyny i dzierżawy · Powiązanie tokenu usługowego z CI przez OIDC · Logowanie z terminala

Jak powstają i są sprawdzane wydania

• Każde wydanie agenta crunu i aplikacji webowej jest podpisane kluczem wydania Ed25519.
• Wydania agenta są publikowane na releases.crunu.com: pliki wykonywalne, pakiety .deb, install.sh i podpisany manifest. Instalator sprawdza SHA-256 pliku wykonywalnego agenta, a crunu self-update sprawdza podpis wydania kluczem wbudowanym w agenta. Polecenie instalacji, które pokazuje aplikacja webowa, zawiera sumy kontrolne z podpisanego wydania.
• Crunu publikuje podpisany manifest aplikacji webowej na app.crunu.com. Przy ładowaniu aplikacja sprawdza ten podpis i własną kompilację z manifestem, a na pasku bocznym pokazuje Signed build. Wybierz to oznaczenie, aby sprawdzić każdy plik witryny. Jeśli coś się nie zgadza, aplikacja ostrzega, żeby nie wpisywać hasła.
• To sprawdzenie działa w kodzie, który dostarczył ten sam serwer. Wykrywa uszkodzone lub pomieszane wdrożenie, ale nie serwer, który zmienia jednocześnie stronę i samo sprawdzenie.
• Kompilacja aplikacji webowej jest odtwarzalna: jeden commit źródeł zawsze daje te same pliki. Strona nie dopuszcza skryptów zewnętrznych i ładuje własny kod z sumami kontrolnymi integralności (CSP i SRI).
• Mało zależności: agent używa tylko biblioteki standardowej Go, a kod przeglądarki zawiera jeden pakiet npm, yaml.

W dokumentacji: Aktualizacja crunu przez self-update

Kopie zapasowe, dostępność i odejście

• Na app.crunu.com baza danych przechowuje do 30 dni historii do przywracania w Cloudflare. We wczesnym dostępie nie obiecujemy żadnego poziomu dostępności. Zobacz Regulamin.
• Miej własną kopię. Aplikacja może pobrać kopię offline każdego środowiska, do którego masz dostęp. Otwiera się twoim hasłem i Secret Key, bez żadnego serwera. Środowiska ograniczone regułą sieciową nie są do niej dołączane.
• Prowadź serwer samodzielnie albo się przenieś. Ten sam serwer działa w Dockerze na twojej własnej maszynie, na Cloudflare Workers, Vercel i Google Cloud Run, a także na AWS App Runner na kontach, które wciąż mają do niego dostęp. Jedno archiwum bez jawnych wartości przenosi go między nimi i to samo archiwum jest twoją kopią zapasową. Zobacz Własny hosting.

W dokumentacji: Eksport i kopia offline · Kopie zapasowe i przywracanie

Co jest przechowywane i jak długo

• Wersje. Każde środowisko przechowuje 100 ostatnich wersji, do 64 MB. Przywrócenie starej wersji zapisuje ją jako nową.
• Dziennik audytu. Logowania, zaproszenia, zmiany ról, zapisane wersje, rotacje kluczy, maszyny, tokeny, linki dostępu i odrzucone żądania trafiają do dziennika, którego wpisy tworzą łańcuch skrótów. Edycja, usunięcie lub wstawienie wpisu przerywa łańcuch, a Verify integrity to pokazuje. Dziennik jest domyślnie przechowywany przez 365 dni, a właściciele mogą ten okres wydłużyć. Wartości nigdy się w nim nie pojawiają, bo serwer ich nie ma.
• Zapisy dostarczeń i usuwanie. Zapis tego, kto otrzymał każdą wersję, jest przechowywany przez 90 dni od ostatniego dostarczenia, a potem łączony w podsumowanie. Usunięcie konta wymaga hasła i Secret Key. Usunięta organizacja od razu staje się niedostępna i wkrótce potem jest usuwana partiami. Pełną tabelę zawiera Polityka prywatności.

W dokumentacji: Dziennik audytu · Wersje i historia

Jeśli przejęty zostanie sam serwer

Projektujemy pod najgorszy scenariusz: wyciek bazy danych, nieuczciwy operator albo przejęte konto w chmurze, po których serwer może odpowiadać, czym zechce. Twoje urządzenia sprawdzają, co przysyła, więc nawet wtedy nie może odczytać twoich wartości, dopisać siebie jako odbiorcy, podmienić klucza, zmienić wersji, przemianować production, podsunąć własnej organizacji ani wsunąć innego klucza, gdy ktoś dołącza. Aplikacje i agenci zapamiętują też najnowszy zaakceptowany stan i odrzucają wszystko, co starsze, więc ponownie przesłana lista dostępu nie przywróci kogoś, kogo usunięto. Zupełnie nowe urządzenie nie ma z czym porównać, więc przy pierwszej wizycie nie wykryje cofnięcia do starszego stanu.

Nadal może natomiast odmówić usługi, czytać metadane i wydać zmodyfikowaną stronę. Alerty sygnalizują logowania z nowych urządzeń, ponownie użyte kody rejestracji, ponownie przesłane tokeny CI i powtarzające się odmowy. Gdy ktoś odchodzi, aplikacja wymienia klucze, które miał, i podaje listę wartości do ponownego wygenerowania. Przy skradzionym urządzeniu Device compromised wymienia klucze twojego konta i rotuje każde środowisko, do którego twoje konto miało klucz.

Jeśli dowiemy się o włamaniu do app.crunu.com, bez zbędnej zwłoki wyślemy e-mail do właścicieli kont, których to dotyczy: co się stało, jakich danych to dotyczyło i co dalej robić. Włamanie do usługi ujawnia zaszyfrowane dane i metadane, a nie wartości w twoich środowiskach, których nie da się odszyfrować bez twojego hasła i Secret Key. To samo zobowiązanie zawiera Polityka prywatności.

W dokumentacji: Offboarding członka zespołu · Rotacja kluczy środowisk · Alerty

Co zależy od ciebie

Szyfrowanie skreśla serwer z listy tego, co może odczytać twoje sekrety. Kilka rzeczy możesz zrobić tylko ty.

• Wydrukuj Emergency Kit przy rejestracji i trzymaj go z dala od swoich urządzeń. Nikt, łącznie z nami, nie zresetuje twojego hasła ani nie odzyska twojego Secret Key.
• Utwórz kod odzyskiwania i przechowuj go osobno od Emergency Kit. Otwiera konto po okresie oczekiwania, domyślnie po godzinie, bez drugiego składnika.
• Włącz drugi składnik i ustaw krótką blokadę bezczynności. Aplikacja domyślnie zapomina twoje klucze po 10 minutach bez aktywności.
• Dawaj każdej osobie i maszynie tylko to, czego potrzebuje, i miej niewielu właścicieli i administratorów.
• Gdy ktoś odchodzi, wygeneruj ponownie u każdego dostawcy wartości, które ta osoba widziała. Rotacja chroni nowe wersje, a nie to, co ta osoba już zobaczyła.
• Jeśli aplikacja ostrzega „Build signature doesn’t match: do not enter your password”, nie wpisuj hasła i powiadom administratora.

W dokumentacji: Ograniczenia · Blokada i limit bezczynności

Audyty i dokumenty

Crunu jest nowe i działa we wczesnym dostępie. Nie ma certyfikatu SOC 2 ani ISO 27001 i nie opublikowano żadnego zewnętrznego audytu.

Te dokumenty opisują, jak usługa obchodzi się z danymi:

• Polityka prywatności: jakie dane mamy, po co i jak długo
• Podprocesorzy: kto prowadzi z nami usługę i gdzie
• Regulamin i Zasady korzystania

Na potrzeby własnych przeglądów właściciele i administratorzy mogą wyeksportować dziennik audytu do JSONL i sprawdzić jego łańcuch skrótów poza Crunu. Gdy ktoś odchodzi, raport ekspozycji pokazuje, które wersje których środowisk ta osoba otrzymała, kiedy i skąd, i możesz go pobrać.

Zgłoś podatność

Napisz na security@crunu.com i opisz kroki, które odtwarzają problem. Nie umieszczaj w zgłoszeniu prawdziwych sekretów.

Podczas testów:

• testuj tylko na własnych kontach i organizacjach albo za zgodą ich właścicieli;
• nie uzyskuj dostępu do cudzych danych i ich nie przechowuj, a jeśli trafisz na nie przypadkiem, daj nam znać;
• nie przeprowadzaj testów odmowy usługi, nie wysyłaj spamu i nie stosuj socjotechniki;
• prowadź automatyczne skanowanie na tyle lekko, by nie wpływało na innych użytkowników.

Potwierdzimy otrzymanie zgłoszenia i będziemy cię informować w trakcie prac. Datę ujawnienia uzgodnimy z tobą, zwykle w ciągu 90 dni od zgłoszenia.

Pełne zasady, w tym zobowiązanie, że nie podejmiemy kroków prawnych wobec badań prowadzonych w dobrej wierze, zawierają Zasady korzystania. Ten sam kontakt jest w security.txt.