Vlákno názorů k článku Tajemství jako služba. V Seznamu se o ně stará Sasanka od Uncaught ReferenceError: - Pěkné a díky za sepsání. Vidím velkou inspiraci...

Pěkné a díky za sepsání. Vidím velkou inspiraci v Vaultu od HashiCorp. Nechcete to uvolnit jako open source?

Mám pár štouravých otázek:

1) píštete, že neexistuje superuživatel, ale nezmiňujete se, jestli data v paměti také šifrujete. Není pak root, který může číst paměť ostatním procesů právě tím superuživatelem? Je občas rutinou vytahovat zapomenutá hesla z paměti procesoru přes gdb nebo strace.

2) jeden z možných útoků v striktně uzavřených sítí není ukrást samotné heslo, ale změnit ho na dopředu známou hodnotu zaneseným trojským koněm. Vedete historizaci hesel a máte pro aplikace pouze read-only přístupy? V rámci namespace mám přístup na vše nebo se ty práva dají dále dělit?

3) Jak jste se vypořádali s logováním? Logujete i přístup k tajemstvím? Hlídáte unikátnost generovaných hesel? Sledujete entropii, aby nešlo záměrně hesla a certifikáty oslabit? Jak analyzujete a kontrolujete to, co se vlastně vygenerovalo a jestli tajemství jsou dostatečně silná? Tohle bývá v praxi docela oříšek udělat to správně a nejednou jsem viděl tokeny plné nul.

4) u regulárních výrazů jsem často naráželi na problém, kdy nešikovný zaměstnanec nebo útočník může vytvořit regulární výraz v takovém tvaru, že zahltí cpu na poměrně dlouhou dobý a vznikne s tím DoS na službu hesel, přesně v téhle situaci často nastává porušení bezpečnostních zásad a dělají se hotfixy, které mohou vést k napadení systémů. Řešíte nějak tuhle situaci?

Dobrý den,

na opensource to zatím není, i když bych rád. Aby to dávalo smysl a živilo to nějaký opensource tým (dnes už jen vydat zdrojáky ven nestačí), musel by se kolem toho tvořit byznys model. A to není úplně náš primární focus.. .možná někdy s tím ARM serverem....

K dotazům:

1) omezím se toliko na konstatování, že superuživatel má bohužel super možnosti a může si vytáhnout i klíč, kterým jsou data zašifrovaná. Proto myšlenkami mířím na dedikovaný ARM s crypto processorem, který by klíč nikdy nevydal, ale data uměl šifrovat / dešifrovat. Pro představu, ten ARM by stačil něco velikosti Raspberry PI (což je i náš ARM dataholder). S takový setupem by šlo data uchovávat i mimo paměť v nějaké databázi.

2) Sasanka toto neřeší, z tohoto pohledu je pouze storage s API. Ale máme interní feature request na generátor hesel, a tam se to nabízí. V rámci namespace může mít člen různá práva, ale jinak se pohybuje po celém namespace. Na jiné účely je jiný namespace. Přístup aplikací je řešen přes aplikační token, který má a měl by být omezen (typicky na daný namespace a read-only pro konzumenty).

3) Logujeme přístup k objektům a generujeme anonymizované metriky. Kromě signing a encrypting keys Sasanka žádná hesla sama o sobě negeneruje (prozatím).

4) jediný regulární výraz je definice scope tokenu, a to je ještě hodně specificky use-case (většinou stačí explicitně zadaný namespace), jinak se regulárky uživatelsky nepoužívají. Takže zatím to není a nebylo téma.

díky za odpovědi. S tím open source to chápu, však většina věcí co Seznam.cz uvolnil zeje prázdnotou a je bez dalších aktualizací.

Ano, proto jsem se na toho superuživatele ptal, ač tu roli nemáte v samotném SW, z principu fungování serverů tam. Je těžké v běžném serveru ty data před rootem schovat. Často lze vidět určité KMS zařízení pro ukládání tajemství ale jsou to drahé krabičky.

Generování samotných tokenů a hesel je pilíř bezpečnosti, neměli byste to nechávat strikně na uživatelých, zejména když máte celý proces integrovaný a automatizovaný, tak nevidím problém úplně uživatele od hesel odstřihnout a nechat vše běžet vlastním životem vč. pravidelné obměny.

Tyhle systémy bývají jedny z prvních na řadě v případě cílených útoků, logováním a hledáním výchylek v dotazech na tajemství je možné poměrně rázně a zavčasu takové útoky detekovat.

Líbí se mi princip fungování kerberosu, kdy se služby bez validní identifikace nejsou schopné ani spojit a komunikovat, škoda, že to postupně umírá. Chápu správně, že pro zvájemnou komunikaci služeb je token dobrovolný a musí si ho každá aplikace sama nějak implementovat a Sasanka řeší pouze distribuci těhle tokenů aplikacím?