#language cs #pragma section-numbers 1 ## 20161106 AK ---- '''česky''' | [[SecurityManual|english]] ---- || ''' Příručka bezpečnosti CAcert (CAcert Security Manual) - český překlad''' || || '''ORIGINÁLNÍ [[https://www.cacert.org/policy/SecurityPolicy.html|Security Policy]]''' jsou zásady {{https://www.cacert.org/policy/images/cacert-policy.png}} podle rozhodnutí '''[[PolicyDecisions#p20140731|p20140731]]''' || || což znamená, že Zásady bezpečnosti (Security Policy, SP) a tato Příručka bezpečnosti jsou závazné pro celou komunitu || || '''POZOR!''' Tento překlad slouží k pochopení popisovaného tématu. '''Právní platnost má POUZE anglický originál!''' || <> ---- == Úvod == <> === Motivace a rozsah působnosti === Tato Příručka bezpečnosti popisuje požadované praktiky a procedury pro bezpečné provozování kritických počítačových systémů CAcert personálem, tak jak jsou identifikovány [[https://www.cacert.org/policy/SecurityPolicy.html|Zásadami bezpečnosti]] (Security Policy, SP). ==== Týká se personálu ==== Viz SP. ==== Mimo rozsah ==== Viz SP. === Principy === Viz SP. === Definice === Viz SP. * Event Log [záznam událostí] - je to seznam cacert-systemlog@lists.cacert.org, jehož archiv je dostupný na https://lists.cacert.org/wws/arc/cacert-systemlog. === Dokumenty a Řízení verzí === ==== Dokument Zásady bezpečnosti (Security Policy) ==== Tato Příručka bezpečnosti (Security Manual) podléhá řízení Zásadami bezpečnosti (Security Policy, "SP") neboli "Zásadami") pro dosažení shody. Zásady určují, co se musí vykonat. Příručku bezpečnosti je vhodné číst současně se Zásadami, protože každý zde uvedený oddíl závisí na Zásadách. ''Myslím, že bychom měli napsat PHP skript ke čtení obou dokumentů a zobrazit jejich odpovídající oddíly vlevo a vpravo...'' [[https://www.cacert.org/policy/SecurityPolicy.html|Zásady bezpečnosti]] podléhají [[https://www.cacert.org/policy/ConfigurationControlSpecification.html|Konfiguraci-Řídicí specifikaci (CCS)]] pro účely auditu. SP jsou ZÁSADY (POLICY) závazné pro klíčový personál. ==== Dokument Příručka bezpečnosti (Security Manual) ==== Tato Příručka bezpečnosti ("SM" nebo "tato Příručka") je dokument o praktikách. Popisuje prováděcí postupy. Spravuje ji tým vedoucích za použití tohoto wiki k řízení verzí. Bude revidována, aby souhlasila se Zásadami (SP) a praktiky i procedury zde dokumentované budou revidovány, aby souhlasily jak se Zásadami (SP), tak s Příručkou (SM). ==== Bezpečnostní procedury ==== Zásady (SP) opravňují vedoucí týmů k vytváření ''procedur''. Jsou to jednoduché a soudržné komponenty bezpečnostních praktik, zpracované jako oddělené dokumenty tam, kde zařadit je do Příručky bezpečnosti (SM) by bylo příliš nepraktické. Tyto dokumenty mají totéž postavení jako tato Příručka a lze je považovat za logicky začleněné do ní. Viz oddíl 10.2 - aktuální seznam procedur. Přídavné praktiky, které jsou určeny stát se procedurami, se během doby, kdy jsou zde vyvíjeny, označí jako '''PROCEDURE''' . ---- == FYZICKÁ BEZPEČNOST == Tento oddíl je spravován vedoucím týmu přístupu (Access Team). ''Diskuse'' '' Poznámky k revizi této sekce - následující připomínky nejsou částí Příručky bezpečnosti (SM):'' * ''Je třeba, aby secure-u [bezpečnostní firma, www.secure-u.de] odpověděla na tyto otázky:'' * [[https://www.cacert.org/policy/CertificationPracticeStatement.php#p5.1|CPS5.1]] odkazuje sem [Fyzické ovládání: umístění a konstrukce sídla, fyzický přístup, napájení a klimatizace, vystavení vodě, prevence a ochrana před požárem, uložení médií, likvidace odpadů, záloha mimo lokalitu.]. * ''[[http://tools.ietf.org/html/rfc3647#section-4.5.1|Chokhani a kol.]] hovoří o:'' {{{ 4.5.1. Ovládání fyzické bezpečnosti . Tato část popisuje fyzické ovládání [uspořádání] v obálce [například budově, kde je umístěno] zařízení entity systémů. . Mohou zde být například tato témata: * Umístění a konstrukce sídla, například konstrukční požadavky na zóny vysoké bezpečnosti a používání uzamčených místností, klecí, trezorů a kabin; * Fyzický přístup, tj. mechanismy pro ovládání přístupu z jedné oblasti zařízení do jiné, nebo přístup do zón vysoké bezpečnosti, např. umístění provozu CA do bezpečného počítačového sálu, monitorovaného strážemi nebo bezpečnostními alarmy a požadovaný přesun ze zóny do zóny má být realizován pomocí žetonu, biometrických čidel a/nebo seznamů povolených přístupů; * Napájení a klimatizace; * Vystavení vodě; * Požární prevence a ochrana; * Úložiště médií, např. požadavek na úložiště záložních médií oddělené, fyzicky bezpečné a chráněné před poškozením ohněm a vodou; * Odpadové hospodářství; * Záloha mimo sídlo. }}} * ''avšak výše uvedené jsou návrhy, nikoli požadavky'' * ''níže jsou uvedeny požadavky z DRC [[https://www.alkas.org/ca_review|kritérií Davida Rosse]]:'' * A.5.a ''CA udržuje dokumentaci svých procedur k zajištění elektronické a fyzické bezpečnosti svého provozu. '' * A.5.c ''Příručka bezpečnosti popisuje, jak jsou jednotlivci oprávněni k přístupu k počítačovému vybavení.'' * A.5.d ''Příručka bezpečnosti popisuje, jak jsou jednotlivci oprávněni měnit...'' * A.5.e ''popisuje bezpečnost fyzického vybavení. Měla by se zabývat:'' * omezením osob v přístupu ke kryptografickému hardwaru * zaznamenáváním přístupů k zabezpečeným kontejnerům * frekvence změn kombinací, šifer zámků, atd. * A.5.g ''popisuje, jak jsou počítačové systémy a ostatní hardware chráněny proti krádeži a neoprávněnému fyzickému přístupu.'' * http://audit.cacert.org/drc/browser.php === Zařízení === Hostování je zajištěno u fy BIT podle smlouvy s firmou secure-u. Viz §9.4. ==== Umístění a konstrukce ==== Zařízení je moderní, pro svůj účel postavené zabezpečené hostitelské centrum v Ede, Nizozemí. CPS5.1.1 odkazuje sem. ==== Napájení ==== Zařízení má (rozšiřitelné) silové připojení 1.2 MW, dvojitou klimatizaci po 0.75 MW (rozšiřitelnou) a dvojitou záloho napájení: UPS a diesel generátory. CPS5.1.3 odkazuje sem. ==== Síťové připojení ==== Zařízení je připojeno na světlovodný okruh [optická vlákna], který zajišťuje dvě geograficky oddělená spojení mezi Ede a Amsterdamem. Jak v Ede, tak v Amsterdamu jsou dva geograficky rozdílné koncové body, též propojené optickými vlákny. Internetový provoz lze v každém místě vést přes Amsterdam Internet Exchange [AMSIX] (http://www.ams-ix.net). ==== Zmírnění katastrofických událostí ==== Zařízení je umístěno 9 metrů nad úrovní moře (NAP). Má tyto prostředky pro zmírnění katastrofických událostí: * systém detekce požáru s vysoce inteligentním časným varováním. * halonový [uhlíko-halogenový plynový] systém prevence požáru, * systém řízení přístupu do budovy a haly hostingu, založený na kamerovém skenu duhovky osob a magnetických přístupových kartách. * uzamčený rošt (rack) * protinárazový plot, stěny z betonových tvárnic (breezeblocks), bezpečnostní dveře do haly hostingu * ochranu proti blesku podle NEN 1014 třídy LP4 ''Je to ono (vše)?'' CPS5.1.4 odkazuje sem. ==== Hodnocení ==== Datové centrum je strukturálně a elektronicky zabezpečeno na úrovni BORG třídy 4. Klasifikace BORG je řízena [[http://www.hetccv.net|Holandským centrem pro prevenci kriminality a pro bezpečnost]] (Dutch Centre for Criminality Prevention and Security) a je definována v [[http://www.hetccv.nl/binaries/ccv/dossiers/kwaliteitsregelingen-en-instrumenten/ccv-regelingen/borg/brl-borg-2005-versie-2-_mei-2007.pdf|Nationale Beoordelingsrichtlijn BORG 2005]] (Národním posouzení BORG 2005 - dostupné pouze v holandštině). === Fyzické aspekty === ==== Počítače ==== Seznam inventáře udává prodejce, model a výrobní číslo, kontakt na údržbu, umístění v roštu (racku), zamýšlené použití (určení), název (alias). Pracovní seznam fyzického inventáře: * [[SystemAdministration/CableIndex]] * [[SystemAdministration/EquipmentList]] * ''{změny jsou zaznamenávány určeným způsobem}'' Právně závazný Seznamu inventáře je uložen v kanceláři sekretáře secure-u. Pro získání kopie seznamu požádejte Výbor secure-u (vorstand@secure-u.de). * ''existuje otevřený požadavek na nahlédnutí do tohoto seznamu'' * ''měla by existovat rutina pro synchronizaci pracovního seznamu s právním (legal, "ostrým") seznamem'' ===== Akvizice ===== Akvizice hardwaru otevírá zvláštní bezpečnostní rizika pro dobře fundované útočníky. * Akvizice nového vybavení se má provádět u dlouhodobé (tradiční) obchodní firmy. Zvolte prodejce s vysokým pohybem zboží ve skladu. * Povaha objednávky nemá být odhalena před dodávkou vybavení (účel, význačná jména/názvy, termín dodání). * Jednotky mají být vybírány náhodně. * Zápisy v záznamníku a v [[SystemAdministration/EquipmentList|inventáři]]: prodejce, metoda objednání, značka a typ, výkonnost/kapacita, statistiky. * Jednotky vrácené na opravu se považují za kompromitované (prozrazené, odtajněné). Akvizici mohou provést správci systémů CAcert, ale v okamžiku zahájení služby [uvedení do provozu] se právní vlastnictví hardwaru přenáší na secure-u a řízení fyzického přístupu se přenáší na Inženýry přístupu. ==== Servis ==== * ''Byly zde kabely, ale kabely byly začleněny do "Počítačů" výše.'' * ''toto není třeba vyplňovat...'' ==== Média ==== ===== Zásobení ===== Inženýři přístupu (Access Engineers) udržují inventář paměťových médií. Inventář má obsahovat typ média a jeho kapacitu. ===== Uložení [do skladu] ===== Hlášení změny stavu má obsahovat: přítomné správce systému (sysadmins), provedené kroky, umístění skladu, atd. ===== Vyřazení ===== Bezpečné zničení má proběhnout jedním z těchto způsobů, v tomto pořadí podle priority: a. znečitelnění fyzickými prostředky, které zničí zápisové plochy a elektroniku, nebo a. zničení licencovanou likvidační firmou, nebo a. zapečetění a bezpečné uložení u secure-u, dokud platnost dat nevyprší. Rok konce platnosti nechť je označen správcem systémů CAcert. Podrobně je postup dokumentován v [[SystemAdministration/Procedures/DriveRetirement]]. === Fyzický přístup === ''CPS5.1.2 odkazuje sem.'' ==== Oprávnění přístupu ==== Oprávnění k fyzickému přístupu se provádí podle popisu v příloze "Appendix B" CAcert-secure-u [[https://svn.cacert.org/CAcert/CAcert_Inc/hosting/MoU-CAcert-secure-u-20130624-michael-bernhard-sebastian-werner-sig.pdf|MoU]], aktualizovaný příslušnými komisemi. ==== Profily přístupu ==== Fyzický přístup je možný pouze prostřednictvím Inženýrů přístupu (Access Engineers) secure-u. Musí být přítomen aspoň jeden Inženýrů přístupu. U logického přístupu ke kritickým serverům CAcert bude přítomen aspoň jeden Správce systémů. * web+db server(y): jeden Inženýr přístupu a jeden správce systémů. * podepisující server: Pro jednoduché akce údržby: Bude přítomen aspoň jeden Inženýr přístupu a aspoň jeden správce systémů. Inženýr přístupu prohlédne příkazy zadané na konzole správcem systémů a zkontroluje, že prováděné operace jsou skutečně jednoduché akce údržby, a označí příznakem (jak lokálně, tak později v seznamu adresátů [mailing list]) jestliže nejsou. Jednoduché akce údržby jsou: * připojení přístupové konzoly, * připojení zálohovacího USB disku, * šifrované zálohování na zálohovací USB disk (přinesený z bezpečného úložiště a pak tam zase odnesený členem secure-u), * reboot serveru, včetně systémových kontrol systému souborů, * restart software protokolu spojujícího podepisovací server s webovým serverem, * nastavení datumu a času serveru, * komprimace deníkových (log) souborů; * podepisující server: Pro složité akce údržby musí být přítomny aspoň tři osoby s oprávněním k přístupu: jeden Inženýr přístupu a dva správci systémů. Tedy dvojitá kontrola fyzického přístupu a "čtyřoký" dohled na logický přístup. Inženýr přístupu musí zajistit přítomnost dvou správců systémů. * pro přístup k fyzickému síťování nebo kabelům je potřebný jeden Inženýr přístupu a buď jeden další, nebo správce systémů. * nekritické servery: jeden Inženýr přístupu a jeden správce systémů. Inženýři přístupu nepracují s daty. ==== Záznamy o přístupu === Fyzické přístupy jsou zaznamenávány a hlášeny na seznam adresátů správy systémů CAcert (viz §10.1). "Seznamy kontaktů" dokumentovanými v MoU [Memorandum of Understanding - mezi CAcert a secure-u] se rozumějí osoby přihlášené k tomuto seznamu. Deníky zařízení jsou uloženy u BIT. ==== Nouzový přístup ==== V souladu se zásadami nejsou pro nouzový přístup definovány žádné postupy. Je-li získán nebo zpozorován nouzový přístup, zakládá se spor a okolnosti se předloží nezávislému arbitrovi. To lze použít k bezpečnému oprávnění "po činu" přístupu v nouzové situaci. ==== Fyzické bezpečnostní kódy a zařízení ==== BIT ovládá přístupový systém na karty, skener očí a zámky roštu. Klíče k zámkům roštu jsou registrovány (není dovoleno je kopírovat). Zástupci secure-u uvedení na seznamu přístupů mají klíč k roštu. BIT má klíč určitého tvaru. ''jak je ten BIT klíč ovládán/kontrolován?'' ---- ---- ---- ---- == LOGICKÁ BEZPEČNOST == Tento oddíl je spravován vedoucím týmu správy kritických systémů (Critical System Administration). === Síť === ==== Infrastruktura ==== Diagramy jsou umístěny ''kde???'' ===== Vnější konektivita ===== Služby viditelné zvenku: * http://www.cacert.org/ * https://www.cacert.org/ * https://secure.cacert.org/ * https://tverify.cacert.org/ ===== Vnitřní konektivita ===== Služby viditelné uvnitř: * SSHD Nekritické systémy se s kritickými systémy spojují pouze pomocí služeb viditelných zvenku (externích) takto: * [[SystemAdministration/Systems/CATS|CATS]] (CAcert Assurer Testing System - testovací systém zaručovatelů CAcert) aktualizuje web a databázi s výsledky testů CATS pomocí HTTPS-POST na URL https://secure.cacert.org/cats/cats_import.php ==== Provozní konfigurace ==== ===== Přístup ===== Všechny porty, na nichž se očekává příchozí provoz, jsou dokumentovány; provoz vedený na jiné porty je blokován. Neočekávaný provoz musí být zaznamenám jako výjimka. ||Protokol||Port||Použití|| ||HTTP||TCP/80||hlavní webový server|| ||HTTPS||TCP/443||hlavní webový server, zabezpečený režim|| ||SSH||TCP/22||pouze ze dvou počítačů vnitřní sítě správy (admin); vzdálená údržba systému|| ===== Výstup ===== Všechny porty, na něž je zahájen výstupní provoz, jsou dokumentovány; provoz vedený na jiné porty musí být zablokován. Neočekávaný provoz musí být zaznamenám jako výjimka. ||Protokol||Port||Použití|| ||DNS||UDP/53 + TCP/53||DNS vyhledávání z hlavní aplikace CAcert|| ||SMTP||TCP/25||odchozí e-maily odeslané hlavní aplikací CAcert|| ||WHOIS||TCP/43||vyhledávání názvů domén, zahájené hlavní aplikací CAcert|| ||HTTP||TCP/80||prohledávání webu, ponejvíce pro aktualizace systému|| ||NTP||UDP/123||synchronizace času se servery času v Internetu|| ||boxbackup||TCP/2201||pouze na backup.intern.cacert.org; pro zálohování on-line|| ==== Detekce proniknutí ==== ''(iang:) toto je řešeno v DRC-A.5.f. kde se říká: "Příručka bezpečnosti popisuje, jak jsou počítačové systémy konfigurovány a aktualizovány ke své ochraně proti škodícím průnikům, neoprávněnému elektronickému přístupu a "malware" (škodlivým programům) a jak jsou jednotlivci oprávněni provádět tyto úkoly."'' ''skutečný test proniknutí může zahrnovat vniknutí do privátního ethernetu, provedené příslušníky secure-u.'' Provoz pro Tunixem spravovanou vnější analýzu provozu firewallu provádí Tunix podle smlouvy se secure-u. Tato služba zajišťuje nepřetržité (24/7) monitorování. ''viz webové stránky Tunixu.'' Přímý provoz do/z kritických serverů CAcert analyzují správci systémů CAcert. === Operační systém === Preferovaný OS pro server s webovou databází je [[http://www.debian.org/releases/stable|Debian GNU/Linux, Stabilní vydání]] (Stable). V určitém okamžiku označí projekt Debian některé novější vydání/verzi operačního systému jako své Stabilní vydání. Předchozí Stabilní vydání získá status [[http://www.debian.org/releases/Oldstable|Starého stabilního vydání]] (Oldstable), ale bude ještě rok udržováno [[http://www.debian.org/security/|bezpečnostními opravami]]; vznikne-li během toho roku nové Stabilní vydání OS, bude jednoleté období údržby zkráceno. Správci systémů CAcert potřebují aktualizovat webový/databázový server ze Starého stabilního (Oldstable) vydání Debianu na nové Stabilní (Stable) vydání Debianu, než přestane Debian project Staré stabilní vydání udržovat.<
> Viz též [[SystemAdministration/Systems/Webdb]]. Podepisující server má také operační systém Debian GNU/Linux, jeho [[http://www.debian.org/releases/etch/|vydání Debian Lenny]], což je Stabilní vydání od února 2009 [patrně tedy zastaralý údaj]. Oproti serveru web/db nemá tento server externí spojení a není vystaven navenek [nemá přístup z Internetu]; proto není aktualizován na nová vydání OS, pokud nemá být někdy v budoucnu zcela přebudován.<
> Viz též [[SystemAdministration/Systems/Signer]]. ==== Šifrování disků ==== Viz [[SystemAdministration/Procedures/DiskEncryption]]. ==== Provozní konfigurace ==== Při uvedení do provozu musí být provedena úplná (zašifrovaná) záloha podle SM§4.3. Nejlépe je provést to ihned po spuštění služby. ==== Opravy ==== Nové bezpečnostní opravy (záplaty) budou aplikovány co nejdříve po jejich vydání prodejcem. Záplaty uvolní prodejce a aplikují se manuálně. Po aplikaci rozsáhlé záplaty se opět provede úplná (zašifrovaná) záloha příslušného stroje, jako výše. Detaily postupu záplaty/aktualizace operačního systému jsou popsány v [[SystemAdministration/Procedures/OperatingSystemPatches]] ===== “nouzové” záplatování ===== === Aplikace === * ''Tato část pojednává o aplikacích napsaných in-house [asi: přímo "doma" v CAcertu].'' * ''Přehled postupů certifikace (Certification Practise Statement, CPS) 6.6 odkazuje pro veškerou informaci sem.'' * ''Text níže byl připsán Inženýru aplikací (Application Engineer), ježto je zastaralý. Vyžaduje revizi.'' Primární úkoly pro správu aplikací jsou: * Instalace podepsaných záplat, * Ověření funkční správnosti, * Okamžitá oprava chyb a kopírování oprav zpět do úložišť, odkud záplaty přišly, * Spuštění ad-hoc databáze skriptů a jiných programů [asi pro zachycení opravy], * Oprava chyb datumu/údajů, * Záloha na úrovni databáze, * Sledování žurnálových záznamů (logs) aplikační úrovně. === Řízení přístupu === * ''OK, tyto seznamy jsou zmatečné. Chyby:'' * ''Lepší názvy - viz níže'' * ''Původní MoU [Memorandum of Understanding, dohoda o porozumění] stanoví, že secure-u má právo veta vůči správcům, kteří mohou na dálku a '''pomocí SSH''' přistupovat k datům. Je třeba oddělit nadřazenost secure-u nad správci systému CAcert, protože secure-u nemá přístup (ani read-only) k datům ani autoritu [oprávnění vidět data].'' * ''Je třeba oddělit správce přistupující z konzole od správců přistupujících vzdáleně přes SSH.'' ==== Přístup z aplikací ==== Kde je to možné, použijí správci systémů prostředky obecné aplikace a budou navrženy změny tam, kde je lépe provádět časté akce pomocí aplikace. ==== Zvláštní oprávnění ==== Seznamy řídicí přístup jsou: * '''Console Access List''' [seznam konzolových přístupů], * v současnosti je spravován přímo Výbory CAcert a secure-u, * přenést jeho správu na Inženýra správy systémů (Systems Administration Engineer). * Tento seznam je nyní umístěn v MoU Appendix B, Access List, kde je označován ''Remote and Virtual Access List'' [seznam vzdálených a virtuálních přístupů]. * '''SSH Access List''' [seznam přístupů přes SSH]; [SSH - Secure SHell - zabezpečený shell (interpret příkazů z příkazového řádku)], * a je udržován vedoucím týmu Správců systémů. * Přímý přístup ke kritickým systémům příkazovým řádkem bude povolen pouze správcům systémů a inženýrům aplikací zapsaným na tomto seznamu. * Správci systémů, kteří jsou na seznamu konzolových přístupů (Console Access List), jsou zároveň členy Seznamu přístupů přes SSH (SSH Access List). * ''Kde je tento seznam? - po stabilizaci poměrů je nutno ho vytvořit.'' * '''Application Engineers List''' [Seznam inženýrů aplikací], * je udržován vedoucím týmu Správců systémů a/nebo vedoucím týmu Posouzení systémů (System Assessment). * Toto je "400-bodový" mechanismus, který poskytuje pouze několik výjimečně používaných funkcí. * Je spravován pomocí přímého přístupu do databáze. * ''Je nutná dokumentace (příručka praktik nebo dokument o postupech), kde budou zapsány příkazy SQL.'' * ''Inženýři podpory (Support Engineer, SE) jsou vedeni [asi: evidováni nebo uvedeni] uvnitř aplikace vedoucím týmu podpory (tuto funkci může zapnout kterýkoli SE).'' ==== Identifikace ==== '''Přístup přes SSH.''' Přístup je přes SSH na "hop" [asi: vložený] stroj umístěný uvnitř sítě a z něj na kritický server (kritické servery). Identifikační klíče SSH (SSH Authentication keys) jsou na obou strojích nastaveny, se zapnutým blokováním IP# [čísla? adresy?]. K přístupu správců systému k osobním, pojmenovaným účtům (každý správce [sysadmin] má jeden) se nepoužívají hesla. Přímé přihlášení a přístup k účtu ''root'' '''není''' povoleno. Veřejný klíč SSH každého správce systému, který má takový přístup, je uložen do ~sysadmin/.ssh/authorized_keys na kritickém serveru, privátní SSH klíč musí být utajen (tj. chráněn heslem na privátním systému) každým správcem systému majícím takový přístup. Žurnálové záznamy (logy) přístupu přes SSH se ukládají na kritický server (kritické servery). '''Přístup on-line.''' Přihlášením na normální účet člena týmu podpory. ==== Odebrání přístupu ==== Proběhne za těchto okolností: * odchod z týmu správců systémů, * označí-li dva členové seznamů s přístupem SSH nebo konzolovým, že se přístup již nevyžaduje, * nařízením arbitra, nebo * nařízením Výboru, Přístup osoby k systémům CAcert může být odebrán dočasně. Odebrání se stane trvalým, když Výbor schválí změnu v seznamu přístupů (Access List). ---- ---- ---- ---- == PROVOZNÍ BEZPEČNOST == Tento oddíl je spravován vedoucím týmu správy kritických systémů (Critical System Administration). === Správa systému === Tím, že pravidelnou prohlídku žurnálu (logu) ohledně úkolů provádí jiný správce systémů, je splněn princip čtyř očí. ==== Privilegované účty a hesla ==== Přímý přístup účtu "root" přes vzdálená připojení (tj. vzdálené přihlášení roota) je zakázáno. Heslo se nesmí za žádných okolností přenášet nezašifrovaným kanálem. Ostatní privilegované účty (databáze, http server, atd.) musí být také konfigurovány, aby nepovolovaly login. Preferovanou metodou pro získání přístupu správce (root) je použití utility ''sudo'' určenými uživateli, jak pro omezenou sadu příkazů, tak všeobecně. Privilegia ''sudo'' se konfigurují pomocí ''/etc/sudoers'' a to tak, aby každý přístup správce, tj. přihlášení při vyvolání ''sudo'', vyžadoval individuální heslo. Přes preferované používání ''sudo'' stále trvá i potřeba hesel "roota", aby byl umožněn nouzový přístup do systému z (fyzické) konzole. Takový přístup by neměl záviset na přihlášeních (loginech) jednotlivých správců systémů, avšak znalost hesla "roota" je omezena na členy seznamu konzolových přístupů (Console Access List, viz 3.4.2.). ===== Oprávnění uživatelé ===== ===== Přístup k systémům ===== Pro přístup k účtům se používá pouze SSH. Všechny pokusy o přístup k účtům budou zaznamenány; neúspěšné pokusy budou označeny k prohlídce. ===== Změny ===== Je povinností systémových správců generovat hesla privilegovaných účtů. Změněná hesla by měla vyhovovat nejlepším praktikám co do délky a složitosti. Každá změna hesla privilegovaného účtu se zaznamená do žurnálu (Event Log). Hesla pro privilegované účty musí být změněna při změně oprávněného uživatele nebo při podezření, že je příslušný stroj kompromitován. Podrobnosti o heslech a související správě tajných informací [např. hesel] a změny jsou uloženy v seznamu [[SystemAdministration/Procedures/PasswordManagement| Procedury správy hesel]] (Password Management Procedures). ==== Požadovaná doba odpovědi týmu ==== Dostupnost odpovědi na systémové události je ''nejlepší úsilí''. ==== Změny procedur správy ==== Všechny změny systémové konfigurace musí být zaznamenávány pomocí RCS. [Remote Control System?] ==== Outsourcing ==== [správa vnější firmou] Outsourcovat lze DNS a OCSP. Viz oddíl 9.4. ''Toto je prostor houpačky.'' (???) === Žurnálování (Logging) === ''CPS4.2 odkazuje sem.'' ==== Rozsah záznamů ==== Žurnály (logy) se udržují a uchovávají takto: ||typ záznamu||minimální doba uchovávání||maximální doba uchovávání|| ||anomální provoz sítě||6 měsíců||12 měsíců|| ||systémové aktivity a události||6 měsíců||12 měsíců|| ||přihlašování (login) a přístup účtu root||6 měsíců||12 měsíců|| ||události aplikací (certifikát, web, e-mail a databáze)||6 měsíců||12 měsíců|| ||požadavky na podpis certifikátu, jak na kryptografický modul (podepisující server), tak na hlavní on-line server||24 měsíců||36 měsíců|| ||změny konfigurace||doba života systému||+12 měsíců|| ''(daniel:) Já bych zřídil [mandate] centrální log server - kompromitovaný [ven do Internetu vystavený?] server, který obsahuje žurnálové záznamy (logy) nepotřebuje tak moc integrity. Doporučuji, aby správci systémů měli pouze read-only přístup na centrální log server. Read-only pohled přístupný jen výboru a správě systému by zlepšil transparentnost.'' ''(wytze:) Také bych to rád viděl takto, ale právě teď to nemohu zřídit [mandate].'' Jak kryptografický modul (podepisující server), tak hlavní on-line server musí udržovat žurnálové záznamy (logy) zaslaných požadavků. ==== Přístup a bezpečnost ==== Každý záznam bude opatřen časovým razítkem. Logy budou "write only" - jen zápis. Logy na nepřístupném podepisujícím serveru budou pravidelně extrahovány pro analýzu. Logy kritických on-line serverů budou denně zálohovány. Přístup k nim je omezen na Správce systémů (Systems Administrators). ''Budoucí vývoj: žurnálové záznamy budou odesílány na centrální log server.'' ==== Automatizované logy ==== Automatizované logy budou prohlíženy nejlépe denně. ==== Operační (manuální) logy ==== Změny konfigurace musí být logovány pomocí RCS. K logu RCS mají přístup pouze Správci systémů (Systems Administrators). Všechny přístupy budou logovány (zapsány) do Event Logu [záznamu událostí] včetně krátkého popisu prováděných aktivit. === Záloha === ''toto spojit s oddílem 3.2.1'' ''CPS 5.1.6 odkazuje sem.'' ==== Typ zálohy ==== Jsou tři typy záloh: * online (provozní) * offline, offsite [ukládaná mimo lokalitu vzniku] (disaster recovery [pro obnovení po havárii]) * kořeny [koř. certifikáty a klíče], offsite (disaster recovery) (viz oddíl 9.2) ==== Četnost ==== Zálohy se budou provádět: * provozní: automaticky - provozní systémy nebo testovací režimy * disaster recovery: manuálně - záloha celého systému při uvedení do provozu (viz oddíl 3.2.1) * kořeny: manuálně (viz oddíl 9.2) ==== Paměť ==== Zálohy pro obnovení z havárie budou ukládány firmou secure-u na bezpečné místo; přístup k médiím musí být řízen. Záložní média lze použít opakovaně, ale musí se na konci své životnosti správně likvidovat (viz oddíl 2.2.3.2). V současnosti nejsou zálohy pro obnovení po havárii distribuovány pro nedostatek prostředků. ==== Expirační doba a opakované použití ==== '''PROCEDURA:''' ''Je třeba napsat zálohovací proceduru včetně:'' * Uložení více záloh na jedno médium (např. externí USB disk). Za výjimečných podmínek (a) vyšetřování incidentu (oddíl 5) nebo (b) nařízení arbitra, budou příslušné zálohy zkoumány a relevantní údaje v nich mohou být extrahovány a uchovány pro tyto účely. Po ukončení výjimky musí být data smazána. ==== Šifrování ==== Zálohy pro obnovu po havárii jsou dvojitě šifrovány použitím šifrovacího systému a veřejného klíče GPG. ==== Ověření záloh ==== Záloha pro obnovu po havárii je po svém vytvoření ověřena, než je odeslána do bezpečného úložiště. Ověření musí být zaznamenáno do Event Logu. U provozních záloh se zvolí soubory a zkontroluje se, zda se dají obnovit. ''Kde je procedura obnovy...? Mendel!'' ==== Správa klíčů ==== Zálohu musí provádět aspoň dva. Papírová dokumentace musí být uložena se zálohou: * konfigurace stroje (operačního systému a jakýchkoli potřebných aplikací) při zálohování po instalaci nového systému * čas a datum * typ formátu. * Musí být přítomen zástupce správců systémů a bezpečnostní firmy secure-u. * Správci systémů s klíči. Jakmile správci systémů ukončí aktivitu, ke které jsou oprávněni, musí odevzdat své klíče, smazat své kopie, nebo jednat podle pokynů arbitra. Kopie všech kořenových hesel a záloha klíčů a přidružených hesel se uchovávají v jedné či více zapečetěných obálkách a ukládají se do sejfu jednoho z členů výboru CAcert. Změní-li se jedno nebo více uložených hesel, pak při nejbližší příležitosti uloží tým Správců systému novou zapečetěnou obálku nadřízenému členu systému k uložení do sejfu obsahujícího kopie. Přidáno pro záznam: [[Roots/EscrowAndRecovery]] stanoví: {{{ Hesla zašifrovaných disků a kořenová hesla přístupu k systémům jsou uložena v zapečetěné obálce u člena výboru Public Officer CAcert Inc. Tento typ klíčů se má měnit periodicky. * Jedna bílá obálka (typu Barional A6), zalepená průhlednou páskou, datovaná 26-11-2008, s podpisem Wytze van der Raay (správce kritických systémů), s identifikací 'backup keys' [záložní klíče] a backup@cacert.org. Obnova kořenových hesel a klíčů SSH ze zapečetěné obálky závisí na rozhodnutí Výboru (Board). Platnost klíčů je třeba periodicky kontrolovat (s datem změny). }}} a {{{ 28. listopadu: Kořenové klíče byly uloženy do zapečetěných obálek, zalepených pak bezpečnostní páskou 3Com. Obálky jsou (dočasně) uloženy, dokud nebude dokončeno úložiště na nizozemském notářství, v CAcert Inc. v soukromém sejfu presidenta Teuse Hagena. }}} ''Komentáře ke dvěma předchozím citacím:'' * ''Pravděpodobně myšleno jako člen výboru '''NEBO''' Public Officer.'' * ''Záznam historie má být uložen jinde? V Event Logu?'' * ''Přidat poznámku, že obnova závisí na rozhodnutí výboru.'' * ''Je nutná procedura pro kontrolu platnosti klíčů.'' ==== Čtení záloh ==== Je-li zkištěn incident, který vyžaduje přístup k zálohám, je zahájen spor s cílem dosáhnout oprávnění. Nouzové akce je pak třeba neprodleně oznámit arbitrovi. === Doba uchovávání dat === ==== Údaje o uživatelích ==== Při ukončení účtu jsou uživatelské údaje uchovávány podle směrnice arbitra. ==== Systémové žurnály (logy) ==== Viz oddíl 4.2.1 o uchovávání systémových logů. Výtahy logů potřebné k vyšetření incidentů a pro arbitra budou navíc uloženy s odpovídajícím hlášením o vyšetření incidentu nebo v souboru případu arbitráže. Vyšetřovatel nebo arbitr odpovídá za oznámení začátku vyšetřování a za identifikaci, které logy jsou citlivé a tedy pod jeho kontrolou. Pro pohodlí vyšetřovatele bude asi třeba logy kopírovat a zabezpečit na jednotce vyčleněné pouze pro vyšetřování. ==== Hlášení incidentů ==== Dokončená hlášení o incidentech budou udržována na bezpečném místě po dobu neurčitou. Jsou-li v uloženém hlášení citlivé údaje, musí být uchovávaná elektronická verze hlášení (nebo jakákoli elektronická data přiložená k hlášení) zašifrována. ---- ---- ---- ---- == ODEZVA NA INCIDENT == Tento oddíl udržuje ??? ''Diskuse.'' ''CPS 5.7 odkazuje sem.'' === Incidenty === Mají několik úrovní: 1. Tunix firewall 24/7 ovládání a monitorování portů; analýza nezašifrovaného provozu. 1. Firewall webového serveru ovládání a monitorování portů. 1. Ovládání aplikací. 1. Podepisující server. Všechny tyto úrovně generují log. === Detekce === V záznamech (logs) musí být hledány anomálie, alespoň jednou týdně; kde je to možné, automatizovaná detekce anomálií by měla co nejdříve upozornit příslušné odpovědné osoby na detekovanou neobvyklou událost. Jedna osoba bude určena jako primární pro sledování logu, bude odpovědná za dosažení takového stupně znalosti logu, který bude dostatečný ke zjištění nových podezřelých anomálií, a za aktualizaci automatických detektorů. === Okamžitá akce === ==== Závažnost a priorita ==== '''Závažnost.''' Anomální události budou klasifikovány do těchto kategorií závažnosti: 1. nepřímá závada (narušení programem) 1. sonda a. automatizovaná sonda (všeobecný pokus o detekci některých běžných slabin) a. směrovaná sonda (specifický pokus zneužít určitou službu) 1. proniknutí (úspěšná změna/převzetí ovládání) a. využití/zneužití, žádné ztráty a. prozrazení/odhalení, možnost ztráty citlivých údajů nebo výdeje certifikátů a. průlom, positivní důkaz ztráty dat 1. odepření služby [Denial of Service, DoS] (úspěšný pokus směrovaný jako zásah do síťové konektivity nebo jiné dostupnosti jedné i více základních služeb) '''Priorita.''' Priorita odpovědi na jakýkoli incident slouží především k zajištění integrity základních služeb a zabezpečení aktivních dat. Kompromitované služby musí být isolovány ihned po detekci prozrazení/kompromitování. Incidenty musí být ukončeny ihned po detekci a za žádných okolností jim nesmí být povoleno pokračovat (ani za účelem vysledování viníka). ==== Komunikace ==== '''Upozornění.''' Jakmile je událost zjištěna, bude zasláno počáteční hlášení o průniku nebo prozrazení těmto osobám: * správcům systémů, * jiným týmům a rolím, * klíčovým osobám dle seznamu a/nebo * výboru. Přesný seznam, příjemců kopií hlášení je určen okamžitě úsudkem člena [asi: který to zjistí] a každý obeslaný člen může hlášení šířit dále. Další osoby mohou poskytnout další informace. '''Válečná místnost.''' Vytvořte chatovací místnost (např. IRC nebo skype) pro okamžité podpůrce (např. jiné správce systémů, secure-u, Výbor, arbitra). Zapněte záznam do žurnálu (logging). Jsou-li potřebná různá zaměření, pomůže několik takových místností. Případy odepření služby (DoS) budou obvykle zpracovány hostitelskými a firewallovými entitami, přes secure-u MoU [Memorandum of Understanding], takže s nimi navažte kontakt. Kontakt se secure-u a jeho smluvními agenturami je definován v MoU, včetně e-mailových adres. Zkontrolujte weby, obsahují-li nouzová telefonní čísla smluvních agentur. ==== Eskalace ==== V případech proniknutí a horších událostí musí být zřízen oddělený dozor a autorita pro nouzové akce. '''Přehled.''' Neodpovídají-li autority potřebám, zahajte spor a předložte přehled situace arbitrovi. Přehled slouží ke schválení a oprávnění akcí a v extrémní situaci k přímým alternativám. Jsou-li údaje prozrazeny, je nezbytná arbitráž. '''Správa.''' Do komunikační smyčky bude zapojen vedoucí týmu. Není-li k dispozici, nebo rozhodne-li tak vedoucí týmu, zastane tuto funkci Výbor (určený člen Výboru; management je zaměřen na zvládnutí situace rozhodováním podle nadcházejících událostí. Správa a arbitráž nejsou v rozporu, naopak by měly spolupracovat. === Vyšetřování === Jakákoli anomální událost (služba/služby neposkytující odpověď, nepředvídané přetížení prostředků, atd.) je co nejdříve zcela vyšetřena. Pokud vyšetření vede k závěru, že mohlo dojít k narušení bezpečnosti, musí být uchován důkaz co možná nejbližší původnímu stavu a jakékoli záznamy žurnálu (logu) týkající se události. Je třeba zkontrolovat, zda: * incident vyžaduje přihlášení Člena ''nebo'' přihlášení není nutné, * účinek na data uživatelů, vydaný certifikát, kořenové privátní klíče === Odpověď === Opravná akce provedená jako odpověď na anomální událost odpovídá klasifikaci závažnosti události. Obvykle pouze události klasifikované jako ''proniknutí'' nebo závažnější budou vyžadovat zmírnění [dopadu], které provede tým správy systému. ==== Proniknutí ==== Úspěšně sondovaná služba bude vyšetřena ["sonda" je (nepřátelský) prostředek toho průniku]: * kontrola potřebnosti služby/softwaru, * identifikace obrany proti sondě, * implementace obrany a * prohlídka oblasti, neobsahuje-li podobně napadnutelná místa. ==== Kompromitování operačního systému ==== [Což pravděpodobně znamená jeho narušení tak, že ho útočník může na dálku ovládat.]<
> V případě kompromitování [narušení] zneužitím zranitelnosti operačního systému musí být narušený systém isolován vnější sítě a forenzně prozkoumán, se všemi příslušnými archivovanými logy. Když aktivita škodlivého programu logy zničila, je třeba nahlédnout do jejich záloh ke stanovení doby a metody narušení. Jakmile vyšetřování zjistí směr narušení [kudy proniklo], bude operační systém úplně vymazán a reinstalován z bezchybné referenční zálohy, jakékoli známé zranitelnosti (zejména ty již [útočníkem] využité opraveny záplatami, všechna lokální hesla a páry klíčů změněny a vytvořena nová bezchybná referenční záloha, než může být systém vrácen do provozu služby. ==== Potenciální prozrazení uživatelských dat ==== Uživatelská data neexistují jinde než v databázích; je-li podezřelá integrita databáze, musí být ze služby odstraněna, dokud není incident urychleně vyšetřen, provedena příslušná protiopatření a databáze obnovena do bezchybného stavu. Všichni ovlivnění uživatelé musí být zpraveni o narušení a o možnosti, že některé změny mohly být ztraceny [vráceny ke stavu před změnou]. ==== Prozrazení kořenového klíče ==== Je-li prozrazen kořenový klíč: 1. Je umístěn off line, včetně svých podkořenů. 1. Je odvolán * v CRL (podkořeny) nebo * oznámením prodejcům (pouze kořenový klíč). Viz oddíl 9.2.4. 1. Je vyvolána procedura pro nový kořenový klíč. Viz oddíl 9.2.1. 1. Je instalován nový kořenový klíč. 1. Certifikáty jsou odvolány a Členové instruováni, aby si dali vystavit nové certifikáty (jako výše, platí totéž i pro podkořen, existuje-li). ==== Kompromitování aplikace ==== Pokud je kompromitována aplikace: 1. Kontaktovat vývojáře aplikace. 1. Uschovat relevantní logy, kód, soubory, podle rady vývojáře aplikace. 1. Vytvořit nouzové patche (vývojář). (Vývojář aplikace může být zároveň jejím prodejcem.) ==== Obnova po prozrazení nebo narušení ==== Jakmile je poškození posouzeno a je zjištěno prozrazení nebo narušení, dohodněte se s arbitrem na opravných procedurách. === Hlášení === '''Hlášení.''' Konečné hlášení bude zapsáno na [[SecurityManual/IncidentReports/|wiki]] a oznámeno všem poškozeným stranám (správcům systémů, Výboru, vývojářům softwaru, secure-u, obětem z řad uživatelů). Mělo by obsahovat: * podrobnosti (datum, hardware, software) * závažnost a popis škod * odezvy a obnova * zmírňující doporučení do budoucna. Odkazy na hlášení jdou z [[SecurityManual/IncidentReports/]] '''Utajení.''' Události by se neměly utajovat, pokud neexistuje jasné a aktuální nebezpečí dalších bezprostředních škod pro uživatele. Jakákoli utajenost by závažně omezila schopnost jiných členů pomoci vyřešit danou záležitost, a obvykle to přinese více škody než užitku. Jakákoli tajná událost musí být předložena arbitrovi. Samotná událost by neměla být utajena, avšak podrobnosti hackerského zásahu mohou být embargovány. Událost by měla být ihned zahájena jako spor za účelem vytvoření přehledu a potvrzení rozhodnutí udržet detaily pod pokličkou. Odhalení průniků a chyb by mělo být provedeno co nejdříve. Není třeba působit nepříjemně nebo děsit lidi. Je-li třeba, určete pokročilejšího Člena, aby sledoval fóra, čistě pro přípravu zpřístupnění informací. ---- ---- ---- ---- == OBNOVA PO HAVÁRII == KDO udržuje tento oddíl?? ''Diskuse.'' || '''TBD''' || '''''ROZPRACOVÁNO''''' || Dále popsaný proces je navržen dle hledisek CISA. ==== Poznámky ==== * ''CPS 5.7 odkazuje sem.'' * ''Viz také [[Advisory/AMinutes20081222|zasedání 20081222]]. První koncept / ROZPRACOVÁNO'' * ''DRC (David Ross Criteria, kritéria D. R.) A.3.l:'' [[https://www.alkas.org/CA_review|CA-přehled]] * ''CPS popisuje procedury CA pro obnovu po haváriích a jiných výpadcích provozu, včetně:'' * ''vytvoření a zabezpečení záložních kopií certifikátů: kořenového, zprostředkujícího, odběratelského'' * ''vytvoření a zabezpečení záložních kopií informací pro určení identity odběratele'' * ''změna hostování CA serverů'' * ''informování odběratelů a veřejnosti o výpadcích'' * ''náhrada oprávněného personálu a předání jemu známých hesel'' === Provozní procesy === [[BusinessProcesses|Provozní procesy]] udržuje Výbor. ==== Základní procesy ==== [[DisasterRecovery|Obnovení po havárii]] stanoví základní procesy jako: 1. kritické systémy 1. OCSP/CRL servery === Doby obnovy === [[DisasterRecovery|Obnovení po havárii]] stanoví dobu obnovy služeb odvolání na 27 hodin. === Plán === 1. Avízo klíčovým osobám podle seznamu. 1. Výbor sestaví a uvědomí potřebný tým 1. Tým obnovení po havárii (Disaster Recovery) se sejde. 1. Plánování a odpověď. === Seznam klíčových osob === Výbor jmenuje důvěryhodný tým klíčových účastníků, včetně: * výboru * všech správců systémů * zástupců vývoje softwaru * zástupců podpory * arbitráže Všichni členové tohoto týmu obdrží rozpis se všemi potřebnými kontakty na každého člena týmu. Podrobné umístění, správu, distribuci a aktualizaci tohoto rozpisu dokumentuje [[SystemAdministration/Procedures/KeyPeopleContacts|Procedura seznamu klíčových osob]] (Key Persons List Procedure). ---- ---- ---- ---- == VÝVOJ SOFTWARU == Tento oddíl je udržován vedoucím týmu Hodnocení softwaru (Software Assessment). ''Odkazy na jiné dokumenty:'' * ''[[PolicyDrafts/DevProcessPolicy|Zásady procesu vývoje]] (Development Process Policy) je původní startovací dokument pro tým vývoje softwaru. Název je nyní zavádějící, měl by raději používat slovo Procedury (Procedures).'' === Oprávnění === Vedoucí týmu vývoje softwaru odpovídá za bezpečnost kódu. === Úkoly === Primárním úkolem je audit a verifikace kódu, nikoli psaní kódu. Předložit změny kódu ke schválení může v podstatě každý. Některé přídavné úkoly, je-li dostatek času: * oprava chyb * přidávání funkcí * návrhy změn architektury * pomoc při předávání kódu Správcům systému. === Úložiště === Integrita centrální verse řídicího systému je klíčová pro integritu aplikací běžících na kritických systémech, takže (počítačový) systém hostící system systém řízení versí musí být spravován pečlivě (avšak v tomto typu systému se nepoužívá šifrování dat). ''To je zvláštní. Znamená to, že toto je kritický systém, nebo ne?'' === Revize === Tým Hodnocení softwaru (Software Asessment) odpovídá za předávání záplat [tj. zejména oprav chyb], které předložili vývojáři komunity CAcert. Tým Hodnocení softwaru se postará, aby všechny záplaty předané týmu Zaručení kvality (Quality Assurance) sledovaly pravidla kódování CAcert a obsahovaly dostatečné instrukce pro aplikaci na testovém systému. Tým Hodnocení softwaru předá záplaty, předložené vývojáři, týmu Zaručení kvality, který otestuje, zda jsou změny funkční dle požadavků. === Test a chyby === Nynější testový systém je udržován [[SystemAdministration/Systems/Test|zde]]. Systém komunikace o chybách je udržován na [[https://bugs.cacert.org/]]. Účty na obou systémech jsou dostupné na žádost Členům (na úrovni zaručovatele) po kontrole malého stupně. ''Malý stupeň kontroly... co to znamená?'' === Výroba === '''''Výroba je ROZPRACOVÁNA (work-in-progress):''''' Po kladné odezvě od týmu Zaručení kvality (Quality Assurance) přesunou hodnotitelé SW (Software Assessors) záplaty do nové revize a připraví build pro správce systémů, aby ti mohli zavést změny do provozního systému. Dodávka záplaty nebo aktualizace týmu správců systémů je hlavním úkolem a vyžaduje, aby oba týmy byly dostupné po určitou dobu. ---- ---- ---- ---- == PODPORA == Tento oddíl je udržován vedoucím týmu Podpory (Support). === Oprávnění === Výbor jmenuje [[Brain/Support/TeamLeader|vedoucího týmu Podpory]], aby vedl tým podpory: [[https://community.cacert.org/board/motions.php?motion=m20100222.1|m20100222.1]]. Software pro ukládání informací o Členech (čili web) je zpravidla řízen [[https://www.cacert.org/policy/ConfigurationControlSpecification.html|CCS]] (Konfigurace-řídicí specifikace, Configuration-Control Specification), viz [[http://audit.cacert.org/svn/DRC/browser.php|DRC-A.1.i]]. Také software pro ''"komunikaci s odběrateli a s veřejností vůbec"'' je specifikován tak, že podléhá řízení. ''[[Iang]]: Nyní (kdy?) provozuje CAcert dva druhy softwaru pro komunikaci s odběrateli a širokou veřejností:'' 1. ''Web, který má své webové uživatelské rozhraní, a databázi e-mailů členů pro formální komunikaci. Tato databáze e-mailů se používá výhradně pod řízením softwaru a pod řízením arbitra, obojí podle CCS.'' 2. ''Skupina serverů "infrastruktury": wiki, mail, blog, lists [seznamy]. Nejsou řízeny auditem, DRC, CCS, ani Zásadami bezpečnosti (Security Policy). Tato skupina obsahuje nástroje podpory schránek (stará) a OTRS na issue.cacert.org (nová).'' Oprávnění pro každou akci Inženýra podpory (Support Engineer) poskytuje: * žádost Člena * příkazy arbitra. Arbitr poskytne "žeton" (token) oprávnění (standardně je to číslo nařízení). === Odpovědnosti === ==== Inženýři podpory ==== Inženýři podpory (Support Engineers, "SE") provádějí toto: * odpovídají na běžné žádosti o informace nebo vysvětlení, přijaté od Členů, * zpravidla na žádost e-mailem zaslaným do kanálů podpory, * udržují utajená jakákoli tajemství, která Členové případně sdělí v e-mailech zaslaných podpoře, * radí uživatelům při běžných technických obtížích, * v blogu, seznamech adresátů (maillists) nebo jiných fórech jako oznámení, * "administrativně" přiřazují zkušenostní bdy (Experience Points), * přímými zásahy do databáze mysql (např. chyby v softwaru), * ''Ale SE nemá přístup do mysql, to by měl tedy dělat Inženýr aplikací?'' * Asistuje systému arbitráže, viz oddíl 8.5, * zapíná role při dosažení příslušných oprávnění, viz oddíl 8.2.2, * mění jména(názvy), případně data narození (DoB), podle oprávnění od arbitra * odvolává zaručení * na žádost zaručovatele, ''navrhl Alejandro, nyní zahájeno jako spor'' jak zaručovatel, tak Podpora, v krátké době. * ''Teus píše: Systém nepovolí opakované zaručení zaručovaného. Má na to však nástroje, když je to potřebné z administrativních důvodů. V takovém případě je to ohlášeno Výboru pro kontrolu. Poslední tři roky jsem takovou akci neviděl, pouze po vyřešení sporu.'' * nebo podle oprávnění od arbitra, * obnova účtu, * formální procedura je [[https://svn.cacert.org/CAcert/Support/PasswordRecovery.pdf| Procedura pro reset hesla]] (Password Reset Proc.)(podle oddílu 1.4.3.) * ''může vidět soukromé otázky'' (Privacy Questions), což spustí e-mail upozornění Členům. * Zrušení účtu uživatele: * '''existuje způsob odstranění účtu, ale úmyslně není dokumentován kvůli chybám.''' * ''(tato část potřebuje školení)'' * ''tato část potřebuje revizi, protože není v souladu s arbitráží'' * zpracuje e-maily Paypal (potvrzení), tak aby: * se poděkovalo dárcům (třeba i za 5 USD) * ověřilo, že uživatel zaplatil poplatek za obnovení hesla ==== Zapnutí rolí ==== Inženýr podpory (SE) odpovídá za zapnutí rolí, jakmile dostane oprávnění. * oprávnění může přijít od Výboru, arbitra nebo možná od příslušných vedoucích týmů? * použije se ŽETON (TOKEN), číslo rozhodnutí nebo číslo nařízení. Existují tyto role: 1. '''umístění''' * umožňuje uživateli měnit databázi umístění * provádí se přidanou položkou menu 1. '''správa''': * tato role se rutinně dává Inženýrům podpory (SE). * základní přístup k účtům, může vidět více potenciálně soukromých údajů uživatele, * ukazuje další menu, * pohled do účtů, * změny data narození (DoB), jméno/název, heslo * odstranit zaručení (ale nemůže změnit body) * nastavit příznaky: * příznak správce organizace (O-Admin) v účtu * umožňuje vytvářet nové účty organizací * další menu ke správě Správce organizace (OA) * nastavuje příznak pro podepisování kódu * umožňuje uživateli vystavovat si certifikáty pro podepisování kódu * řízeno [[https://www.cacert.org/policy/CertificationPracticeStatement.php#p4.2.6|CPS 4.2.6]] (Přehled postupů certifikace 4.2.6), který stanoví: ''"Certifikáty pro podpis kódu jsou dostupné pouze zaručovatelům."'' * byla by chyba udělat změnu softwaru, aby to dělal automaticky? *nebo, aspoň nyní, aby Podpora praktikovala u všech zaručovatelů nastavení tohoto příznaku. * zamyká účet, aby nemohl uživatel zaručovat, * zamyká účet, aby se uživatel nemohl přihlásit, * zapíná pro uživatele proces zaručení Tverify, * nastavuje roli správce (Admin) (to může nastavit kterýkoli správce s rolí Admin) * Správce organizace * nastavuje příznak TTP 1. '''role Tverify''' * povoluje uživateli přidat další body - ???? netestováno 1. "zrušit účet" jen označí účet jako nepřístupný * pro skutečné zrušení/smazání musí zašifrovat data 1. '''role propagace''' 1. '''role TTP''' * ''zeptejte se Roberta, jak role TTP funguje'' * potřebuje 200 "starých bodů" 1. '''Zaručovatel organizací (Organisation Assurer, OA)''' * OA vytváří účet organizace * příznak Zaručovatele organizace (Org-Assurer) - ???? kontrola názvu * Proces: * OA přidává domény * OA přidává Správce organizací (O-Admins) dané organizace do účtu organizace * Podpora posílá e-mail Správcům organizací (O-Admins), ptá se, mají-li nová menu pro tvorbu certifikátů organizace. 1. '''role Správce organizace (Organisation Administrator, O-Admin)''' * Kterýkoli Správce organizace (O-Admin) může vydávat certifikáty, jednat za organizaci * O-Admin s 50 body zaručení může být označen jako MASTER * MASTER může také přidávat nové podsprávce (sub-Admins) * ''chyba, všichni správcové organizací (O-Admins) musí být zaručovatelé, podle Zásad zaručování (AP) nebo Zásad zaručování organizací (OAP).'' ==== Triage [Třídění] ==== Vedoucí týmu podpory jmenuje a řídí tým prvních reagujících osob, známý jako [[Support/Triage|Triage (třídění)]]. Jeho role je přísně omezena na analýzu přicházejících žádostí o podporu a směrovat je na příslušná místa. Namá přístup ke speciálním funkcím. Členové týmu Triage musí být zaručovatelé a musí souhlasit s prací podle Zásad bezpečnosti (Security Policy) a této příručky, avšak v současnoszi se u nich nevyžaduje ABC (Arbitrated Background-Check, asi: arbitrážní ověření). Viditelná informace a prováděné akce jsou zhruba podobné, jako u zaručovatelů. Triage se považuje za trénink na Inženýra podpory (Support Engineer) a další role v CAcert. ==== Vedoucí týmu Podpory ==== Vedoucí týmu Podpory odpovídá za: * revizi akcí podpory, * zvláště pro postoupení arbitráži, * hlášení Výboru, * vytváření vodítek pro běžné záležitosti, * lidské zdroje týmu podpory: * nábor, * školení a testování, * trvalý dohled, * počáteční ověření, * vede dialog s týmy Vývoj softwaru a Správa systému, * k tomu používá bugscacertorg, * poskytuje zpětnou vazbu pro vylepšování funkcí, * komunikuje s Členy * (řídí Výbor) příležitostně oznamuje změny zásad nebo dohod, atd. * když má Člen problém ohledně certifikátu, * u nouzových stavů a narušení [provozu CA], * v případě sporů zahájených proti Členům * nebo pod řízením arbitra === Kanály === Příchozí komunikace nastává na základě těchto metod: * zasílání zpráv z kontaktního formuláře webu [[http://www.cacert.org/index.php?id=11|Contact Us]]. Výsledek: a. předání do otevřeného fóra pomoci (níže), nebo a. přeposlání e-mailové zprávy do support@. * e-mail do support@ a. (historicky) e-maily byly archivovány ve schránce IMAP, spravované týmem Třídění ([[Support/Triage|Triage]]). Tento nástroj je zastaralý a bude vyčištěn podle definice [[Technology/Support/DataRetentionPractice|Data Retention Practice]] (Praktiky ukládání dat). a. (nově) e-mail se posílají do sledovacího a lístkového systému OTRS na issue.cacert.org. Je to nový systém, který je v současnosti modifikován pro účely Podpory. Může ho také využívat arbitráž. * IRC na cacert# (bez přihlášení, veřejný kanál, neformální pomoc) * otevřené fórum pomoci, v současnosti seznam adresátů na cacert-support (archivován, veřejný kanál, neformální pomoc) [[Support/Triage|Triage]] (Třídění) může předat komunikaci ze support@ do těchto kanálů: * Kanál Inženýra podpory [Support Engineer] (pomocí OTRS). * Do fóra arbitráže (pomocí OTRS a manažer/správce případu (Case Manager, CM) ji pak zašle do seznamu adresátů cacert-disputes). * Toto rozhraní je (má být) spravováno společně Podporou a Arbitráží. * Do otevřeného fóra pomoci. Inženýři podpory (SE) nyní udržují polosoukromou místnost v IRC na #se pro všechny členy podpory a privátní seznam adresátů cacert-support-engineer@. Zmíněné systémy (schránka, OTRS, IRC, seznam adresátů otevřeného fóra pomoci) představují systémy "infrastruktury" udržované na virtuálních strojích (VM) týmem infrastruktury. Tyto systémy nejsou dosud označeny Výborem jako "kritické systémy" a nejsou proto přísně vázány Zásadami bezpečnosti (Security Policy). Inženýři podpory mají přístup přes webové nástroje podpory, k tomu mají oprávnění podle oddílu 3.4.2. Triage tento přístup nemá. === Záznamy a žurnály (logy) === Každý návod od arbitra přichází s ŽETONEM [TOKEN]. * žetonem je standardně číslo případu, * ŽETON [TOKEN] představuje oprávnění provést akci podpory, * Inženýr podpory zaznamená ŽETON [TOKEN] do žurnálu podpory, * ''do vhodné 'škatulky'... prozatím podle předmětu e-mailové zprávy [Subject:].'' * (později to má dělat patřičná funkce softwaru), * toto je navrhovaná, nově vzniklá procedura a nebyla dosud vyzkoušena, * ''jak řešit, když osoba z podpory aplikuje nařízení v pozdějších podobných případech???'' * ''ostatní systémy by měly usilovat o emulaci metody základního žetonu.'' Všechny kanály podpory spadají pod žurnál. * Příchozí e-maily na support@ jsou: * obsahem schránky IMAP ve složce Archives (archivy), jakmile ji odbaví Triage. ''Podle [[Technology/Support/DataRetentionPractice|Praktik ukládání dat]] se musí archivy vyčistit.'' * udržuje OTRS. ''Jak? Dokument.'' * Provoz Inženýra podpory * byl žurnálován do seznamu adresátů support-se v období listopad-prosinec 2009 jako dočasné opatření. ''Podle [[Technology/Support/DataRetentionPractice|Praktik ukládání dat]] se musí archivy vyčistit.'' * Všem členům fóra arbitráže byl udělen přístup. * udržuje OTRS. ''Jak? Dokument.'' === Arbitráž === Arbitráž je hlavní odpovědností týmu podpory: * ten určuje, které žádosti o podporu musí být ohlášeny arbitráži. Jsou to například žádosti, které: * vyžadují autoritu/oprávnění, * vyžadují asistenci nebo jsou komplikované, * nehodí se na existující (precedentní) nařízení, které je zaštítěno autoritou, * žadatel chce zahájit spor, * požaduje ukončení dohody nebo zrušení účtu. [[CCA4.2|Dohoda komunity CAcert, odst. 4.2]] [CAcert Community Agreement, CCA], * když Inženýr podpory (Support Engineer) jedná v nouzové situaci bez oprávnění, * když požadavek, žádost, příkaz přichází z úředního nebo zjevně oficiálního zdroje. Viz [[https://www.cacert.org/policy/SecurityPolicy.html#9.3.2|Zásady bezpečnosti 9.3.2]] (Security Policy, SP). * poskytuje podporu * podle popisu v [[https://svn.cacert.org/CAcert/Support/SupportOfArbitration.html|Pokynech pro Podporu arbitráže]] (Guidelines for Support of Arbitration), * a je-li žádán [[https://svn.cacert.org/CAcert/Arbitration/arbitration_case_manager.html|Manažer/správce případu]] (Case Manager), nebo * je-li veden arbitrem. Vedoucí týmu odpovídá za revizi rozhodnutí založit, '''a rozhodnutí nezaložit.''' * ''historie, revize dosavadních akcí? jsou nějaké v běhu? Jak dlouho (přibližně) trvá každý krok?'' * ''kde je dokumentace?'' === Odkazy === * "praktiky" a pokyny jsou v * procedurách v [[https://svn.cacert.org/CAcert/Support/|SVN]] [web s "ostrou" provozní dokumentací] * pokyny na [[Support/Team|wiki]]: pro [[Support/SE|Inženýry podpory]] (Support Engineers), [[Support/Triage/CZ|tým třídění]] (Triage) a pro [[Support/OpenHelpForum|otevřené fórum podpory]] naší komunity. * support ''zavináč'' cacert ''tečka'' org je hlavní závazný kanál podpory * issue.cacert.org je sledovací a lístkový systém OTRS [tracking & ticketing system]. * Přehled postupů certifikace (Certification Practise Statement, CPS) 4.9, 5.2.1 * [[https://svn.cacert.org/CAcert/Arbitration/arbitration_case_manager.html|Pokyny pro Správce případů (Case Manager) / Příručka]] * seznam adresátů cacert-support ''zavináč'' lists ''tečka'' CAcert ''tečka'' org. ---- ---- ---- ---- == ADMINISTRATIVA == Tento oddíl je řízen Výborem. === Personální věci === ==== Role a odpovědnosti ==== Některé přídavné úkoly rolí: * Inženýr přístupu (Access Engineer): Kapacitní plánování, spojení s hostingem, sleduje správnost procedur Správců systémů. * Správce systému: Kapacitní plánování systému, údržba softwaru a záplat [tj. oprav nepřidávajících nové funkce, např. bezpečnostních] třetích stran a monitorování žurnálu [logu] za účelem detekce narušení/průniku. * Hodnotitel software: Viz oddíl 7.2. * Podpora. Viz oddíl 8.2. * Vedoucí týmů: Koordinace a porady o záplatách (patches), opravách a funkcích. Nábor. * Všichni: spojení s ostatními týmy. * Výbor: Koordinuje vedoucí týmů a týmy. Udává priority oprav funkcí a chyb. ==== Personální úrovně ==== Každý tým má alespoň 3 osoby, raději více. Vedoucí týmu by se měl přímo podílet na náborové kampani. Až se tým rozšíří, podílí se vedoucí týmu méně na vlastní práci týmu a více se věnuje koordinaci a budování týmu. ==== Postup u nových členů týmu ==== Obecný postup: 1. Tým navrhne přibrat někoho. 1. Tým provede přípravu a interview. 1. Ověření nového člena se spustí zahájením sporu v arbitráži. 1. Nařízení a doporučení arbitráže se předloží Výboru ke schválení. 1. Výbor nového člena schválí. 1. Tým novou osobu začlení. ==== Procedury ověření ==== Ověření nového člena se spustí zahájením sporu, jmenováním osoby angažované jako respondent. Použije se arbitráž jako administrativní krok, což neznamená, že by vznikl "spor" vedený proti oné osobě. Bude zvolen arbitr, který není závislý na osobách, ale je znalý dané oblasti. Manažer případu (Case Manager) poskytne podporu a naplní roli "čtyř očí". Ověření nového člena je vedeno podle směrnic daných arbitrem. Procedura ověření je proto primárně řízena arbitrem a změny navržené jinou osobou se provedou podle výsledku konsultace. [[https://svn.cacert.org/CAcert/Arbitration/BackgroundCheckProcedure.html|Procedura ověření]] (též Arbitrážní ověření, Arbitrated Background Check, ABC) je řízena arbitrem. ===== Rozsah ===== Vyšetřování prozkoumá: * specifické znalosti v dané oblasti: programovací schopnosti (u vývojářů); znalost příslušného operačního systému (OS) (u správců systému), atd. * komunitní stav musí být aspoň zaručovatel * případné konflikty zájmů budou známy před zahájením ověření ===== Pokrytí ===== Interview odhalí, se kterými zásadami ověřovaný souhlasí a zjistí jakékoli výhrady, které by kandidát mohl mít. <> ===== Dokumentace ===== Arbitr po vydání nařízení shromáždí a udržuje dokumentaci. Arbitr musí od kandidáta získat právně závaznou dohodu ohledně platných zásad a procedur pro účely běžného zabezpečení (včetně mlčenlivosti, důvěrnosti, ochrany soukromí a/nebo smluv specifických vzhledem k úkolům). ''Metoda získání závazné dohody je (v současnosti) věcí arbitra.'' Ověření je podporováno týmy, nebo osobou řízenou Výborem. ===== Ochrana soukromí pro kritické role ===== ==== Oprávnění ==== ==== Bezpečnost ==== Záležitosti bezpečnosti budou hlášeny vedoucímu týmu a založeny jako bezpečnostní chyba/selhání. Není-li uspokojivě vyřešena, bude ohlášena Výboru Board nebo bude zahájen spor. Vedoucí týmů nesmí stát v cestě eskalaci a podpoří aktivní pozorování ze strany Členů a eskalace v nejistých záležitostech tak, aby byla získána praxe/praktika. Bez důvěry v eskalaci by členové mohli příliš váhat se ozvat. ==== Ukončení působnosti ==== Jsou nutné tyto kroky: 1. Veřejné klíče SSH dané osoby se zablokují. 1. Hlavní "tajemství" se změní (například hesla roota, SSH klíče serveru) 1. Nižší hesla se analyzují na citlivost (například hesla databáze) 1. Účty, záznam aktivit atd., jsou dána do úschovny (escrow). 1. Kopie uschovaných kořenových klíčů nebo záloh se zabezpečí. Vedoucí týmů také zajistí body 1,2 výše, když osoba přenese svou aktivitu (přejde) z jednoho týmu do jiného. ==== HR(?) a školení ==== Existují testy technických znalostí týmů. Téměř formální kvalifikace ve věcech bezpečnosti má váhu, není však požadována. Některé role vyžadují širší znalost bezpečnostních praktik. ''Poznámka: bude připraveno školení a (CATS) testy pro některé části tohoto procesu.'' === Správa kořenového klíče === * ''z CPS 5.6. DRC-A.2.t-u'' * Co platí pro kořeny [zřejmě: pro kořenové certifikáty a klíče], platí též pro pod-kořeny, není-li stanoveno jinak. * Ačkoli to není výslovně uvedeno, je také podchycena jakákoli jiná podpisová aktivita. Je to například nové podepsání (re-signing) pod-kořene [zprostředkujícího certifikátu]. ==== Generování kořenového klíče ==== * ''z CPS 6.2.6; viz [[Roots/NewRootsTaskForce]] - informace o projektu nových kořenů.'' Procedura generování kořenových klíčů je umístěna [[Roots/CreationCeremony|zde]]. ==== Záloha a úschovna (escrow) ==== '''Média.''' Jako úschovna kořenových klíčů budou použity dva USB "disky" (dva spolu slepené - z důvodu spolehlivosti). Bude použito dvojité zašifrování, a to systému souborů a OpenPGP. Hesla musí být generována automaticky a ručně přenesena na papír. Pod-kořeny: kopii uschová vedoucí týmu Správců systémů. Hesla mají členové týmu. pro účely obnovy po havárii jsou jak podkořeny, tak doprovodná hesla také uschována Výborem, a to stejným způsobem, jako kořen nejvyšší úrovně. ''Výbor se má poradit, jak je třeba uschovat kořen nejvyšší úrovně.'' ''Poznámka: stále zbývá vyřešit záležitost CRL, který je třeba vytvořit v rozumné době pomocí kořene nejvyšší úrovně (podepíše CRL pomocí podkořenů.'' ==== Obnova ==== * ''A.3.l'' Procedura pro obnovu kořenů ze zálohy a úschovny (výše) bude umístěna [[Roots/EscrowAndRecovery|zde]]. ''ale není dosud napsána.'' ==== Odvolání ==== Oprávnění k odvolání vydá Výbor nebo arbitr, viz oddíly 5, 6. '''Metoda.''' Kontaktovat každého prodejce a zaznamenat chybu, vyžádat označení kořene jako "nedůvěryhodného" [untrusted] v prodejcově seznamu kořenových certifikátů. Být připraven potvrdit žádost komunikací přes zabezpečený kanál. Poznámky: * V PKIX (Public Key Infrastructure X.509) neexistuje způsob, jak odvolat kořenový certifikát. Nelze použít CRL/OCSP. * Každý prodejce má vlastní metodu, jak odvolat kořenový certifikát. * Výše uvedená metoda je podle [[http://wiki.mozilla.org/CA:Recommendations_for_Roots]], avšak nejsou to zásady. * Pro prodejce třetích stran bude udržován seznam adresátů. Odebírání a zasílání je moderováno. * ''srovnat/revidovat jiné oddíly, které pojednávají o odvolávání.'' * ''přidat poznámku k 3pv-DaL [asi: 3rd party vendors - Disclaimer and License = prodejci 3. stran - dementi a licence] odkazující na tento seznam.'' === Právní aspekty === ==== Odpovědnost ==== Konečnou odpovědnost v právních záležitostech má Výbor. * Viz [[https://www.cacert.org/policy/CertificationPracticeStatement.php#p9.15|CPS#9.15]] (Přehled postupů certifikace, Certification Practise Statement). * Platí zákony NSW (Nového jižního Walesu, tj. státu Austrálie, domova CAcert Inc.). Naše arbitrážní fórum (Arbitration Forum) je fórum, kde se debatuje o právních otázkách. * Výbor přijal model [[http://europa.eu.int/eur-lex/lex/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:EN:HTML|European Data Protection Directive]] (Evropské směrnice pro ochranu dat). Viz [[http://www.cacert.org/index.php?id=10|Zásady ochrany soukromí]]. * Australský zákon o digitálních podpisech je "technologicky neutrální" model. Viz [[https://www.cacert.org/policy/CertificationPracticeStatement.php#p1.4.3|CPS#1.4.3]] o používání digitálních podpisů. * Viz [[https://www.cacert.org/policy/CertificationPracticeStatement.php#p5.8.1|CPS#5.8.1]] o přenosu CA. . [Český překlad CPS (Přehled postupů certifikace) je [[https://www.alkas.org/cacert-docs/CAcert - přehled postupů certifikace.docx|zde]].] ==== Odpověď na (právní) dotaz zevně komunity ==== Nemáte oprávnění odpovídat na dotazy ohledně bezpečnosti nebo právního importu. Arbitrova nařízení vás mohou instruovat a stát se vaším oprávněním jednat. Toto ustanovení je velmi silné a je zde pro vaši vlastní ochranu a ochranu celé komunity Členů. Může být proti vám použito sociální inženýrství, abyste byli donuceni porušit toto pravidlo. Dejte vědět vedoucímu svého týmu a/nebo důstojníkovi pro bezpečnost o každém požadavku přicházejícím mimo formální kanály, i když je třeba triviální. ''Zde pravděpodobně potřebujeme procedury/příručku sociálního inženýrství.'' === Outsourcing === Fyzická aktiva a hosting jsou zpravidla poskytována a udržována, jak je stanoveno v Memorandu porozumění mezi CAcert a secure-u z 24. června 2013 a občas doplňováno/upravováno. Ke změnám MoU je nutné schválení oběma Výbory, jak CAcert, tak secure-u. Uvědomte si, že před MoU mezi CAcert a secure-u platilo velmi podobné MoU mezi CAcert a Stichting Oophaga, původně dohodnuté 10. července 2007 a naposledy doplněno 9. června 2009. Všechny tyto dokumenty lze nalézt zde: [[https://svn.cacert.org/CAcert/CAcert_Inc/hosting/|svn CAcert_Inc/hosting]]. MoU stanoví, že odpovědnost za fyzické změny/doplňky (hardwaru), hostování a řízení přístupu k hardwaru má secure-u. secure-u sestavuje hostingovou smlouvu s BIT, Ede. * ''Jak daleko jde/sahá toto SM/SP? Počítáme sem i BIT, Ede?'' * ''MoU pravděpodobně potřebuje přepsat, až se "usadí prach" na SP/SM.'' . SP/SM = Security Policy/Security Manual = Zásady bezpečnosti/tato Příručka bezpečnosti. === Důvěrnost, utajení === Kritické role CAcert se vzdávají určitého dílu ochrany soukromí, aby zachovaly soukromí ostatních. ---- ---- ---- ---- == ZDROJE == === Kontakty === * Správci systémů a Inženýři přístupu jsou zapsáni v otevřeném seznamu adresátů (mailing list) [[https://lists.cacert.org/wws/info/cacert-sysadm|cacert-sysadm]]. * Žurnál všech manuálních změn je v seznamu adresátů [[https://lists.cacert.org/wws/info/cacert-systemlog|cacert-systemlog]] (Event Log). * Seznam klíčových osob je ''ROZPRACOVÁN'' (work-in-progress). * Výbor CAcert je na seznamu adresátů [[https://lists.cacert.org/wws/info/cacert-board|cacert-board]]. * Osoby z secure-u: * Výbor je [adresa e-mailu] vorstand ''at'' secure-u ''dot'' de, * Inženýři přístupu (fy secure-u) jsou [adresa e-mailu] cacert-access ''at'' hobby ''dot'' nl (a také na cacert-sysadm). ''Poznámka:'' Všechny seznamy adresátů se v současnosti provozují na "infrastruktuře" strojů, které nejsou kritické. ''Sledujte.'' ==== Kontaktní seznam klíčových osob ==== Procedura pro udržování a distribuci seznamu soukromých kontaktů klíčových osob je dokumentována v [[SystemAdministration/Procedures/KeyPeopleContacts]]. === Dokumenty === 1. [[https://www.cacert.org/policy/SecurityPolicy.html|Zásady bezpečnosti]] (Security Policy) jsou pod [[https://www.cacert.org/policy/ConfigurationControlSpecification.html|CCS]] pro účely auditu. 1. Memorandum porozumění (MoU) se secure-u je umístěno v [[https://svn.cacert.org/CAcert/CAcert_Inc/hosting/MoU-CAcert-secure-u-20130624-michael-bernhard-sebastian-werner-sig.pdf]] '''Seznam procedur:''' <> * [[https://svn.cacert.org/CAcert/Arbitration/BackgroundCheckProcedure.html|BackgroundCheckProcedure]] [kontrola pozadí] * [[https://svn.cacert.org/CAcert/Support/PasswordRecovery.pdf|Password Reset Procedure]] [reset hesla] * [[https://svn.cacert.org/CAcert/Arbitration/arbitration_case_manager.html|Příručka správce případu]] (Case Manager Handbook) * [[https://svn.cacert.org/CAcert/Support/SupportOfArbitration.html|Guidelines for Support of Arbitration]] [podpora arbitráže] ==== Poskytnout / najít ==== * ''umístění diagramů infrastruktury'' * ''umístění inventáře'' - [[SystemAdministration/EquipmentList|Inventář]] nalezeno zde. === Související dokumenty === * [[RiskAssessment|Hodnocení rizik]] najít také referenční příručku CISA (CISA manual reference) pro DR. * starší [[https://svn.cacert.org/CAcert/SecurityManual/|rozpracované dokumenty o bezpečnosti]] * CAcert-secure-u MoU (datováno 24. června 2013) * Některé části Příručky bezpečnosti jsou přímo odkazovány z [[https://www.cacert.org/policy/CertificationPracticeStatement.php|CPS]] (Přehled postupů certifikace, Certification Practise Statement), zvláště oddíly [[https://www.cacert.org/policy/CertificationPracticeStatement.php#p5|5]] a [[https://www.cacert.org/policy/CertificationPracticeStatement.php#p6|6]]. [Český překlad dokumentů zásad, včetně CPS, je umístěn [[https://www.alkas.org/cacert-docs|zde]].] ---- . CategoryAudit . CategoryPolicy . CategorySystems . CategorySupport