Architektura privátního cloudu

Bankovní institut vysoká škola Praha Katedra informatiky a kvantitativních metod

Architektura privátního cloudu Diplomová práce

Autor:

Bc. Jakub Fišer Informační technologie a management

Vedoucí práce:

Praha

Ing. Vladimír Beneš, Ph.D.

2016

Prohlášení:

Prohlašuji, že jsem závěrečnou práci zpracoval samostatně a v seznamu uvedl veškerou použitou literaturu.

Svým podpisem stvrzuji,že odevzdaná elektronická podoba práce je identická s její tištěnou verzí, a jsem seznámen se skutečností, že se práce bude archivovat v knihovně BIVŠ a dále bude zpřístupněna třetím osobám prostřednictvím interní databáze elektronických vysokoškolských prací.

V Praze, dne 30. června 2016 Bc. Jakub Fišer

Poděkování Děkuji vedoucímu práce Vladimíru Benešovi za jeho vstřícný přístup, užitečné rady a za prostor, který mi při realizaci práce poskytl. Poděkování patří i mé partnerce, která mě během psaní práce psychicky podporovala. V neposlední řadě si poděkování zaslouží i všichni tvůrci Open Soure softwaru, bez kterých by tato práce zcela jistě vůec nemohla vzniknout.

Anotace Práce se zabývá návrhem platformy pro jednoduchou instalaci, nastavení a provoz osobních cloudových služeb, jako např. e-mail, fotogalerie, internetové úložiště souborů a synchronizace, či kalendář, hostované na nezávislých hardwarových nebo softwarových systémech. Cílem je navrhnout platformu, která bude plně pod kontrolou uživatele. Důrazem je kladen na bezpečnost a soukromí dat jako protiklad k běžným cloudovým službám hostovaných na serverech poskytovatelů. (např. Google Apps, Dropbox, či Seznam e-mail) Klíčová slovat: cloud, platforma, soukromí, bezpečnost, uživatel

Annotation The thesis is aimed at designing a simple platform that would allow a simple installation, configuration and operation of several private cloud services such as e-mail, photo gallery, data storage and sync or a calendar, hosted on independent private software and hardware systems. The goal is to design a platform that would be owned and controlled exclusively by the user with emphasiss on security and privacy as an alternative to common proprietary cloud services (such as Google Apps, Dropbox or Gmail). Key words: cloud, platform, privacy, security, user

Obsah

1 Úvod

7

2 Úvod do problematiky Cloudu

9

2.1

Rozvoj cloudových služeb

. . . . . . . . . . . . . . . . . . . . . . . . .

10

2.2

Druhy cloudových služeb . . . . . . . . . . . . . . . . . . . . . . . . . .

11

2.2.1

Elektronické komunikace . . . . . . . . . . . . . . . . . . . . . .

12

2.2.2

Sociální sítě . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

2.2.3

PIM - Personal Information Management . . . . . . . . . . . . .

14

2.2.4

Datová úložiště . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

2.2.5

Tvorba a poskytování obsahu . . . . . . . . . . . . . . . . . . .

17

Proč privátní cloud? . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

2.3.1

Zdroje dat v cloudu . . . . . . . . . . . . . . . . . . . . . . . . .

18

2.3.2

Základní koncepty privátního cloudu . . . . . . . . . . . . . . .

19

2.3

3 Koncept a architektura privátního cloudu

21

3.1

Koncept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21

3.2

Operační architektura . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

3.2.1

Doména . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

3.2.2

Síť . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

3.2.3

Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

3.2.4

Operační systém . . . . . . . . . . . . . . . . . . . . . . . . . .

28

3.2.5

Webserver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

3.2.6

php-fpm a uwsgi . . . . . . . . . . . . . . . . . . . . . . . . . .

31

3.2.7

Databáze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

34

5

3.3

3.4

3.5

3.2.8

Postfix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

35

3.2.9

Spamassassin a Amavis . . . . . . . . . . . . . . . . . . . . . . .

38

3.2.10 Dovecot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

39

3.2.11 SSL, šifrování, certifikáty . . . . . . . . . . . . . . . . . . . . . .

40

Aplikační architektura . . . . . . . . . . . . . . . . . . . . . . . . . . .

42

3.3.1

Uživatelská databáze . . . . . . . . . . . . . . . . . . . . . . . .

42

3.3.2

Modoboa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

44

3.3.3

Prosody . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

47

3.3.4

ownCloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

48

Platforma privátního cloudu . . . . . . . . . . . . . . . . . . . . . . . .

50

3.4.1

Základní služby platformy . . . . . . . . . . . . . . . . . . . . .

50

3.4.2

Doporučené rozšíření služeb platformy . . . . . . . . . . . . . .

61

Instalátor privátního cloudu . . . . . . . . . . . . . . . . . . . . . . . .

62

4 Závěr

67

5 Seznam zkratek

70

6

Seznam tabulek

72

7

Seznam obrázků

73

8 Seznam použité literatury

75

6

1. Úvod Není to tak dávno, co lidé kroutili hlavou, když jim někdo řekl slovo cloud a přemýšleli, co to vlastně je a k čemu jim to může být dobré. Dnes by si asi žádný člověk ze zemí vyspělého světa a nejspíše i velké části zemí třetího světa nedokázal svůj život bez toho samého cloudu představit. Cloud přinesl lidem služby až do domů, do bytů a do rukou. Počítače, tablety, televize, mobilní telefony a další zařízení umožňují lidem konzumovat služby, které ještě před několika lety neexistovaly nebo byly špatně dostupné a neobvyklé a před několika desetiletími byly vymožeností akademických obcí a technologických korporací. Cloudových služeb je mnoho. Patří mezi ně např. e-mail, služby pro synchronizaci dat (Dropbox, iCloud), internetové televize, geolokační služby a mnoho dalších. Uživatelé jim po gigabajtech poskytují svá soukromá a často citlivá data a jen občas si uvědomují, že data v cloudu vůbec nemají pod kontrolou, že neví, co se s jejich daty v cloudu děje, kdo všechno k nim má přístup a jak snadné je tato data získat a zneužít. Troufám si odhadnout, že i z těch lidí, kteří nějaká rizika v cloudu tuší, si většina neuvědomuje jejich rozsah a možné důsledky. Především vezmeme-li v úvahu, že data, která uživatel vědomě pošle do cloudu jsou jen částí dat, která se tam ve skutečnosti dostanou. Tato práce se zabývá cloudem z pohledu běžného uživatele / konzumenta služeb. Nemá ambice zabývat se a navrhovat řešení pro privátní cloudové služby na firemní úrovni, avšak výstupy této práce lze v tomto oboru použít přinejmenším jako inspiraci – většina použitých technologií je na firemní použití ve velkém rozsahu připravena.

7

Cílem této práce je poskytnout běžným lidem nástroje, jak některým rizikům cloudu předejít a některá zmírnit tím, že jim nabídne způsob, jak alespoň část služeb, na které jsou od cloudu zvyklí, mohou provozovat na vlastních serverech a mít je tak plně pod kontrolou. Mezi tyto služby patří zejména e-mail, správa souborů a synchronizace dat, on-line kalendář a adresář volitelně synchronizovatelný např. mobilním telefonem, zálohování fotografií z telefonu a vytváření veřejně nebo omezeně přístupných galerií (včetně možnosti ochrany heslem) a v neposlední řadě (ale na poslední chvíli) také možnost částečně obejít vynucené používání aplikace Facebook Messenger, kterou v době, kdy tato práce byla již téměř hotová, začal Facebook protlačovat ke koncovým uživatelům bez možnosti se jí vyhnout.

8

2. Úvod do problematiky Cloudu Americký Národní institut standardů a technologie (NIST) definuje Cloudové služby (cloud computing) následovně[1]: “Cloud computing je model vývoje a poskytování služeb způsobem umožňujícím všudypřítomný a pohodlný přístup ke službám a zdrojům (např. servery, datová úložiště, aplikace a další služby) prostřednictvím počítačových sítí a bez časového nebo místního omezení, který může být rychle vytvořen a poskytnut koncovému uživateli s vynaložením pouze minimálního úsilí ze strany poskytovatele i uživatele.” V této definici se v podstatě shoduje s názorem Qusay Hassana, který tvrdí, že cloud computing je výpočetní model poskytovaný na principu on-demand, založený na autonomních a sítově propojených zdrojích informačních technologií. Poskytovatelé cloudů nabízejí klientům služby s předem definovanou kvalitou a podmínkami prostřednictvím Internetu jako balíčky snadno použitelných, škálovatelných a levných služeb na principu předplatného.[2] Podle mého názoru je cloud pouze tzv. buzzword[3], který se začal používat koncem první dekády 21. století a který jen dává nové moderní jméno modelům a principům poskytování služeb, jenž v té době dávno existovaly. Domnívám se, že již první superpočítače byly cloudy. Jen se s nimi nekomunikovalo pomocí sítě Internet, ale prostřednictvím děrných štítků a pásků, magnetických pásků, dedikovaných terminálů, tiskáren a dalších periferií. Koncepce způsobu využívání služeb cloudu a superpočítačů je ve své podstatě totožný – uživatel službě předá data a požadavky, služba domluveným způsobem výsledek zpracování dat a požadavků uživateli doručí zpět. S rozmachem 9

počítačových sítí na univerzitách společně s rozvojem víceuživatelských operačních systému, jako např. UNIX®[4], docházelo k čím dál tím většímu rozmachu služeb, které se dnes nazývají cloudové. V době rozmachu mikroprocesorů to byl terminálový přístup k mainframům univerzitních nebo armádních kampusů, později různé BBS a s rozmachem Internetu se jednou z nejtypičtějších cloudových služeb stal E-Mail. Před rozvojem širokopásmového připojení k Internetu byly možnosti poskytování služeb prostřednictvím cloudu omezené. Klienti platili za objem přenesených dat nebo za čas strávený připojením, typicky na připojení pomocí telefonní (dial-up nebo ISDN) nebo satelitní sítě, jejichž výkon nebyl podle dnešních měřítek nijak velký. Pamatuji si, že u vytáčeného (dial-up) připojení byla průměrná rychlost stahování v lepších případech okolo 5 kB/s, což např. znamenalo, že jedna průměrná nahrávka ve formátu MP3 o délce tří minut se stahovala přibližně hodinu, pokud uživatel zároveň připojení k Internetu nezatěžoval i jinými činnostmi. Stahování videa, natož streamování v reálném čase, bylo v té době nepředstavitelné. Až začátkem 21. století začalo docházet k postupnému rozvoji poskytovatelů DSL společně s rozvojem komunitních i komerčních Wi-Fi sítí v České republice, jenž mělo za následek strmý nárůst dostupnosti a kvality připojení k Internetu. Toto zdržení bylo způsobeno především monopolem tehdejšího SPT Telecom, který byl vládou stanoven až do konce roku 2000[5].

2.1

Rozvoj cloudových služeb

S rychlejším, levnějším a méně limitovaným připojením k Internetu se začaly rozrůstat i komerční služby poskytované prostřednictvím této celosvětové sítě. Princip poskytování služeb se od 70. let příliš neměnil, měnil se však způsob uživatelského přístupu a obsah a objem dat. Internet začali používat obyčejní lidé bez odborných IT znalostí a uživatelské rozhraní a způsob používání cloudových služeb se musel zjednodušit tak, aby tito lidé byli schopni služby konzumovat bez vynaložení zvláštního úsilí. Došlo k rozmachu služeb, které byly náročné na datové přenosy, jako např. streamování

10

zvukových a později i obrazových dat. Nejznámějším představitelem audiovizuálního streamování je dnes patrně YouTube. Primárním prostředníkem komunikace mezi uživatelem a cloudem se stal internetový prohlížeč (nejznámější např. Mozilla Firefox či Google Chrome) používající protokol HTTP a v současnosti i HTTP21 . Uživatelé si postupně odvykli používat jiné metody přístupu k cloudovým službám (tzv. tlusté klienty) a do internetových prohlížečů se postupně dostaly i robustní aplikace, jako např. WYSIWYG textové procesory či tabulkové kalkulátory.

2.2

Druhy cloudových služeb

Z pohledu běžného uživatele lze v současnosti rozčlenit druhy poskytovaných cloudových služeb do těchto kategorií: • elektronická komunikace • sociální sítě • PIM • datová úložiště • tvorba obsahu uživatelem • transformace a poskytování obsahu uživateli Komerční i nekomerční cloudové služby v sobě běžně tyto kategorie různě kombinují. Příkladem může být osobní internetová fotogalerie (transformovaný a poskytnutý obsah), která čerpá data z uživatelského datového úložiště, nebo sociální sítě, které v sobě běžně zahrnují nějakou formu elektronické komunikace, a další. 1

protokol HTTP2 je podporován i v navrženém konceptu privátního cloudu

11

2.2.1

Elektronické komunikace

Elektronické komunikace definuji jako obecnou kategorii všech prostředků vzdálené komunikace mezi uživateli prostřednictvím sítě Internetu jak v reálném čase (instant messaging nebo IRC ), tak i dávkové (e-mail). Typickými představiteli služeb instant messagingu (IM) jsou starší služba ICQ, moderní XMPP (známé též jako Jabber) nebo Facebook Messenger. IRC (obr. 2.1) je též starší, ale dodnes používaný způsob hromadné komunikac oblíbený zejména mezi IT odborníky, kterému konkuruje např. služba Slack[6], určená zejména různorodým skupinám uživatelů bez IT znalostí, marketingově poskytovanou “v cloudu”. IRC je však dle definice také cloudovou službou. Protokol IRC vznikl v roce 1988 a v roce 1993 byl standardizován jako RFC1459[7], protokol komunikace Slack podle dostupných informací standardizovaný nijak není.

Obrázek 2.1: Ukázka hromadné komunikace prostřednictvím IRC, zdroj: vlastní zpracování Na obrázku 2.2 je názorně předveden typický příklad IM, v tomto případě komunikace 12

protokolem XMPP mezi uživatelkou Alice a uživatelem Jakub, kteří shodou okolností oba používají stejný server. Jakub používá webové rozhraní privátního cloudu (pravá část), Alice používá počítačový program Gajim (levá část).

Obrázek 2.2: Ukázka individuální komunikace prostřednictvím decentralizovaného protokolu XMPP, zdroj: vlastní zpracování

2.2.2

Sociální sítě

Collins English Dictionary definuje pojem sociální síť následovně[8]: “webová stránka, která umožňuje svým uživatelům vzájemnou interakci, typicky prostřednictvím žádostí ostatním uživatelům o přidání do svého seznamu kontaktů, vytvářením různých zájmových skupin nebo publikováním obsahu, ke kterému mohou následně ostatní uživatelé sítě přistupovat” Tato definice je výstižná, ale není dle mého názoru úplná - sociální sítě v 21. století poskytují uživatelům mnohem víc služeb (např. IM), aktivně vyhledávají obsah, který by mohl uživatele zajímat, poskytují autentizační mechanismy pro služby třetích stran, 13

nabízejí jednoduchou formu sdílení obsahu formou “stránek”, apod. Nejznámějšími příklady sociálních sítí jsou patrně Facebook a LinkedIn. V České republice vznikaly již na přelomu tisíciletí podobné sociální sítě, např. stále fungující NyX nebo síť Lidé.cz, která v sobě sdružovala některé prvky seznamovacích stránek, uživatelských profilů a znala koncept “přátel” podobně, jako ho používá Facebook. Všechny tyto sociální sítě jsou (byly) uzavřené, provozované soukromými subjekty a bez možnosti kontroly dat ze strany uživatelů. Například síť Facebook si “pamatuje” vaši kompletní historii všeho, co uživatelé prostřednictvím této sítě publikovali, včetně soukromých zpráv.

2.2.3

PIM - Personal Information Management

Služby kategorie PIM poskytují uživateli možnost správy a synchronizace vlastních osobních dat adresářového typu. Obvykle se jedná o data jako telefonní seznam, seznam kontaktů (obr. 2.3, osobní a sdílený kalendář (obr. 2.4), poznámky, úkoly (tzv. TODO), a často je součástí PIM služeb i E-Mail. V korporátním prostředí jsou často služby PIM poskytovány uživatelům prostřednictvím známé aplikace Outlook a samotná data jsou uložena na firemním serveru Exchange. Prostřednictvím sítě Internet podobné služby nabízí např. Zimbra2 , nebo Google Apps3 .

2.2.4

Datová úložiště

Internetová datová úložiště byla na této síti obrazně řečeno odjakživa. Prvními datovými úložišti, která by se podle současných měřítek dala klasifikovat jako cloudová, byly různé veřejné a komunitní FTP servery. S rozvojem technologí a především s rozvojem širokopásmového připojení k síti Internet (a tedy nárůstu “datachtivých”, ale nezkušených uživatelů) však FTP servery přestaly postačovat, neboť jejich použití bylo pro uživatele obvykle složité a pro poskytovatele velice špatně kontrolovatelné – FTP protokol neumožňuje příliš efektivně vynucovat různá omezení a většina komerčních 2 3

https://www.zimbra.com/ https://apps.google.com/

14

Obrázek 2.3: Ukázka PIM aplikace “Kontakty”, zdroj: vlastní zpracování

Obrázek 2.4: Ukázka PIM aplikace “Kalendář”, zdroj: vlastní zpracování 15

řešení poskytování datového prostoru nějakou formu regulace ke svému účelu, tedy generování zisku, potřebuje. Patrně nejznámější náhradou FTP serverů, a blíže současnému pojetí cloudu, byla na počátku 21. století služba RapidShare – tehdy nadstandardně vysokokapacitní úložiště, jehož obchodní model byl založen na opačném principu, než bylo v té době obvyklé. Data mohl na servery této služby ukládat každý bezplatně, zpoplatněno bylo pouze stahování. Tento obchodní model je i v současnosti stále efektivní, avšak samotný RapidShare zanikl v březnu roku 2015[9]. V České republice adoptoval tento obchodní model například služba Ulož.to4 . Technické parametry zmíněných služeb nesplňovaly nároky pro “osobní” uživatelská datová úložiště, zejména neomezené, jednoduché, zabezpečené a ideálně bezplatné používání pro osobní data uložená v adresářové struktuře (soubory a složky), vyhledávání, zálohování a synchronizaci dat mezi počítači a dalšími zařízeními. S poskytováním “osobních” datových úložišť otevřela trh až v roce 2008 firma Dropbox, Inc.[10] Úložiště Dropbox je skutečně “osobní” a nízká kapacita poskytovaného úložného prostoru je uživatelům kompenzována zcela odlišným způsobem práce s tímto úložištěm. Zatímco úložiště typu RapidShare umožňovala pouze ukládání jednotlivých souborů (byť velkých) nezávisle na sobě a bez jakékoliv struktury (např. neexistoval seznam nahraných souborů, který by se dal procházet, nebylo možné vyhledávat, soubory nebyly vázány k žádnému uživatelskému účtu), Dropbox poskytuje úložiště vycházející z běžné adresářové struktury, na kterou jsou uživatelé zvyklí z operačních systémů. Úložiště Dropbox je možné pomocí jednoduchého programu k počítači “připojit” podobně jako například přenosný USB disk a uživatel po připojení může s daty v cloudu pomocí svého operačním systému pracovat transparentně. Prostřednictvím úložiště Dropbox bylo možné synchronizovat data mezi více počítači a také soubory například selektivně zveřejňovat. Na podobném principu fungují i další cloudová úložiště. Mezi nejznámější patří patrně 4

http://www.ulozto.cz

16

Google Drive a iCloud. Tyto služby se, na rozdíl od Dropboxu, snaží poskytovanému datovému úložiště dodávat i nadstandardní “přidanou hodnotu”. V případě Google Apps se jedná například o možnost přímé editace textových a tabulkových souborů, u iCloudu o synchronizace kontaktů a hudby s knihovnou iTunes.

2.2.5

Tvorba a poskytování obsahu

Když měl někdo na začátku 21. století “svoje stránky na Internetu”, obvykle to znamenalo, že se jedná o člověka technicky zdatného se zkušenostmi s IT, neboť stránky bylo nutné psát “ručně”, tj. přímo v jazyce HTML. Cloud dal možnost vytvářet vlastní stránky do rukou i uživatelům bez znalostí technických principů fungování a návrhu webových stránek. Vznikly různé CMS systémy, které umožňovaly tvorbu obsahu bez nutnosti starat se o formu, formátování, grafiku a strukturu. Stačilo pouze napsat obsah. Současné cloudové služby umožňují uživatelům vytvářet obsah nejen z textu, ale i z obrázků, zvuků a dalších multimédií. Uživatel může vytvořit například fotogalerii pouze tím, že své fotografie “nahraje do cloudu” a zvolí, jak má jeho galerie vypadat. V České republice je jedním z poskytovatelů takových služeb např. Rajče.net5 . Dalším příkladem může být možnost založit si vlastní internetový deník (tzv. blog) prostou registrací u jednoho z mnoha poskytovatelů této služby (nejznámější je patrně služba Wordpress.com6 ). Poskytování dat z cloudu se od běžného “brouzdání po Internetu” liší především tím, že poskytovaná data jsou vázána na konkrétního uživatele či skupinu uživatelů, jsou personifikovaná. Příkladem může být např. již zmíněný obchod s hudbou iTunes – uživatel spravuje v aplikaci iTunes svou osobní knihovnu, která je prostřednictvím cloudu poskytována k přehrávání kdykoliv a kdekoliv na každém počítači, telefonu nebo iPodu, který si uživatel do této knihovny připojí. 5 6

http://www.rajce.net http://wordpress.com

17

2.3

Proč privátní cloud?

Fakt, že všechny výše uvedené příklady jsou příklady služeb cloudových, je prokazatelný především tím, že všechna data, která jsou prostřednictvím těchto služeb přijímána a odesílána, jsou uložena na serverech, které tyto služby poskytují a klienti k těmto datům pouze nějakým způsobem vzdáleně přistupují, tj. data nejsou pod kontrolou jejich původců a příjemců. Jakákoliv data, která uživatel “nahraje do cloudu”, již v cloudu zůstanou a není obvykle v možnostech uživatele jejich další zpracovávání, šíření a ukládání jakkoliv ovlivnit. Privátní cloud je koncept, který umožní uživatelům úplnou kontrolu nad jejich daty se zachováním většiny výhod cloud computingu, tedy zejména [1]: “všudypřítomný a pohodlný přístup ke službám a zdrojům (např. servery, datová úložiště, aplikace a další služby) prostřednictvím počítačových sítí a bez časového nebo místního omezení, který může být rychle vytvořen a poskytnut koncovému uživateli s vynaložením pouze minimálního úsilí ze strany poskytovatele i uživatele”. Poskytovatelem se v tomto případě stává uživatel sám.

2.3.1

Zdroje dat v cloudu

Přijímání a poskytování dat je základní vlastností každého cloudu. Prakticky všechny moderní cloudy sbírají data od uživatele bez jeho vědomí a často i bez informovaného souhlasu. Privátní cloud je odpovědí na otázky, které by si měl uživatel komerčních cloudových služeb pokládat: četl a pochopil jsem podmínky provozu služeb, když jsem se registroval na Facebook? Kolikrát jsem za poslední rok “odklikl” změnu podmínek zpracování osobních údajů na Googlu? Pamatuji si ten dlouhý text, který se mi zobrazil na displeji chytrého telefonu při prvním zapnutí? Četl jsem podmínky EULA, když jsem naposledy aktualizoval Windows na verzi 8.1 nebo dokonce na verzi 10?

18

Podmínky použití a zpracování osobních a poskytnutých informací známých cloudových služeb jsou velice rozsáhlé (viz obr. 2.5) a není v možnostech běžného uživatele se v těchto podmínkách orientovat.

Obrázek 2.5: Porovnání náhledů obchodních podmínek a podmínek zpracování osobních údajů největších hráčů na IT trhu, zdroj: vlastní zpracování Všechny cloudové služby (i operační systém Windows je dnes z větší části služba) sbírají mnoho uživatelských dat a posílají je na servery poskytovatelů. Součástí odeslaných dat nejsou jen data, která uživatel vědomě poskytl (např. obrázky z fotoaparátu na telefonu či adresář telefonních kontaktů), ale mnoho jiných dat uživatele a o uživateli, s jejichž existencí často uživatel ani není seznámen. Chytré telefony do svých cloudů kontinuálně posílají podrobné informace o vaší poloze, informace o nainstalovaných aplikacích, historie vyhledávání na Internetu a v některých případech i hlasové záznamy (např. Siri[11]).

2.3.2

Základní koncepty privátního cloudu

Za základní premisu konceptu privátního cloudu považuji právo uživatele nakládat se svými daty podle sebe a právo na úplnou kontrolu nad těmito daty. Myšlenka privátního cloudu je založena na uživatelské poptávce po službách cloudového typu a zároveň čím dál tím větším obecném povědomí o problematice soukromí na Internetu. Základem každého cloudu jsou uživatelské účty a data. Nad těmito daty jsou následně vytvořeny různé cloudové služby – například ty uvedené výše v části Druhy cloudových služeb. V privátním cloudu budou uživateli poskytovány obvyklé služby, na které je zvyklý 19

z ostatních cloudů, s tím rozdílem, že infrastruktura a data v privátním cloudu budou v majetku a pod kontrolou uživatele a to včetně způsobu, jakým bude k těmto datům řízen přístup pro ostatní uživatele, případně pro veřejnost. Aby byl cloud cloudem, je nutné jej provozovat tzv. “na Internetu”, tedy mít nějaký server, který je připojen k Internetu a na který může uživatel ukládat svá data a jeho prostřednictvím poskytovat cloudové služby. V této práci se pokusím takový koncept navrhnout a materializovat jej do podoby funkčního prototypu.

20

3. Koncept a architektura privátního cloudu V této kapitole se budu zabývat návrhem konceptu architektury privátního cloudu. Na základě uvedených principů vznikl funkční prototyp tzv. self-hosted 1 cloudového prostředí poskytujícího několik základních cloudových služeb. Hlavním přínosem celého konceptu je vytvoření uživatelsky jednoduchého instalátoru, který kompletně automatizuje nasazení celé platformy privátního cloudu, včetně instalace a konfigurace všech základních služeb a nastavení. Tato kapitola vyžaduje na straně čtenáře alespoň základní technické a terminologické znalosti v oblasti provozu webových aplikací nebo ochotu si tyto znalosti během čtení doplnit. Pro příležitostné čtenáře a laické zájemce o provoz privátního cloudu jsou z této kapitoly zajímavé především části Modoboa, Platforma privátního cloudu a Instalátor privátního cloudu.

3.1

Koncept

Privátní cloud je založen na několika vrstvách a poskytuje základní cloudové služby, které je možné volitelně rozšířit. Koncept předpokládá provoz na vlastním serveru a na vlastní doméně2 , nad kterými 1

“self-hosted” znamená provoz (webových) aplikací vlastními silami, obvykle na vlastních serverech a typicky bez komerční technické podpory tohoto provozu 2 “doménou” v tomto případě myslím běžné internetové doménové jméno, u kterého má uživatel

21

má uživatel plnou kontrolu. Server může být libovolné zařízení připojené k Internetu s veřejnou IPv43 adresou a architekturou i386 nebo x86_64 schopné spustit operační systém Debian GNU/Linux 8 (Debian Jessie). Nejjednodušší je provoz na tzv. VPS, tedy Virtuálním Privátním Serveru, který lze v současnosti koupit jako službu za cenu v řádu jednotek stokorun měsíčně. Mezi základní poskytované služby patří: • e-mail, kompletní e-mailové řešení, včetně IMAP přístupu, MSA/MTA, webového rozhraní a SPAM filtru • datové úložiště, dostupné pomocí klientské aplikace, webového rozhraní a WebDAV, s možností automatické synchronizace dat mezi zařízeními (PC, telefon, atd.) a sdílením dat s veřejností, volitelně s ochranou heslem • IM komunikace s možností komunikovat s ostatními uživateli cloudu, s uživateli Facebooku a jakýmikoliv jinými uživateli jakékoliv decentralizované sítě založené na protokolu XMPP Velice snadno pak uživatel může svůj cloud rozšířit například o tyto služby: • adresář kontaktů, synchronizovaný s telefonem i dalšími zařízeními pomocí CardDAV protokolu a dostupný pomocí webového rozhraní • kalendář, synchronizovaný s telefonem i dalšími zařízeními pomocí CalDAV a dostupný pomocí webového rozhraní, včetně možnosti sdílení mezi uživateli cloudu i s veřejností • fotogalerie, vycházející z datového úložiště, s možností automatického nahrávání fotografií z telefonu po vyfocení, vytváření webových galerií a možností galerie zveřejnit, volitelně s ochranou heslem Platforma privátního cloudu umožňuje rozšiřování služeb prakticky neomezeně a mnoho takových rozšíření již existuje a jejich aktivace je v navržené platformě triviální (doslova “jedním klikem”). Výše zmíněné příklady jsou jen zlomkem aktuálně kontrolu nad DNS záznamy; doporučuji registrovat si doménu druhého řádu (např. frantovo.cz), ale není to nutné 3 IPv6 není přímo podporován, ale při správné konfiguraci bude fungovat také

22

dostupných rozšíření. Součástí řešení je i jednoduchý instalátor s pouze zcela nezbytnými uživatelsky konfigurovatelnými parametry. Tento instalátor je navržen tak, aby jej mohli použít i laičtí uživatelé. V následujících kapitolách postupně rozeberu různé aspekty návrhu celé architektury: • operační architektura obsahuje návrh prvků a aplikací infrastrukturního charakteru a nízkoúrovňových služeb • aplikační architektura obsahuje návrh podpůrných aplikací pro provoz plaformy a některých služeb a způsob instalace a konfigurace • platforma privátního cloudu popisuje volbu platformních aplikací, jejich vlastnosti a způsob použití a konfigurace • instalátor privátního cloudu popisuje řešení replikovatelné instalace konfigurace celé operační i aplikační platformy založené na konceptu “Infrastructure as Code” Aby byl cloud skutečně privátní, je nutné zajistit co nejvyšší míru kontroly nad celou provozní architekturou od síťové infrastruktury, přes hadrwarové prostředky, operační systém, podpůrné aplikace až po samotnou cloudovou platformu.

3.2

Operační architektura

Privátní cloud i ostatní cloudy jsou specifickou variantou webové aplikace a jejich provoz vyžaduje vhodné operační prostředí, tj. hardware, operační systém, systémové a provozní programy, a aplikace. V této kapitole se budu věnovat návrhu externích a interních aspektů architektury operačního prostředí pro provoz aplikační vrstvy nutné k provozu cloudové platformy. Na obr. 3.1 je znázorněno zjednodušené schéma operační architektury privátního cloudu s vyobrazením komponent, které se přímo podílejí na komunikaci a poskytování služeb cloudu. Nepřímé služby a prvky operační architektury (např. SSL, síť, DNS, 23

operační systém, apod.) ve schematu pro zachování přehlednosti vyobrazeny nejsou.

Obrázek 3.1: Zjednodušené schéma operační architektury, zdroj: vlastní zpracování

3.2.1

Doména

Jakákoliv služba provozovaná prostřednictvím sítě Internet v současnosti vyžaduje pro svůj provoz identifikátor, pomocí kterého se lze k dané službě připojit. Pro služby dostupné prostřednictvím Internetu se používají identifikátory URL, resp. URI, jejichž součástí je i doména 2. a vyšších řádů. Vzhledem k rozsahu a charakteru poskytovaných služeb je nutné k jejich provozu zajistit i existenci domény (libovolného) řádu a možnosti nastavit potřebné DNS záznamy. Pro provoz privátního cloudu je nutná existence nejméně DNS záznamů uvedených na obrázku 3.2. Na obrázku jsou v červeném rámečku uvedeny záznamy pro provoz privátního cloudu na doméně diplomka.jakubfiser.cz: • řádek 5 – zajišťuje existenci libovolné subdomény; toto nastavení je nutné k logickému oddělení jednotlivých nízkoúrovňových služeb, které jsou provozovány na jednotlivých subdoménách, např mail.diplomka.jakubfiser.cz nebo cloud.diplomka.jakubfiser.cz, např. pro případ nutnosti provozu těchto 24

Obrázek 3.2: Ukázka nastavení DNS záznamů pro provoz privátního cloudu na doméně diplomka.jakubfiser.cz ve webovém rozhraní registrátora Web4u.cz, zdroj: vlastní zpracování služeb na oddělených serverech • řádek 6 – zajišťuje nastavení serveru pro příchozí e-maily pro doménu diplomka.jakubfiser.cz a všechny subdomény4 • řádek 7 – záznam typu A pro hlavní doménu • řádek 8 – záznam typu A pro mail. doménu, dle RFC2181[12] nesmí MX záznam ukazovat na alias, ale výhradně na A (nebo AAAA) záznam řádek 9 – záznam typu A pro im. doménu (určenou k provozu XMPP), dle RFC2782[13] nesmí SRV záznam ukazovat na alias, ale výhradně na A (nebo AAAA) záznam • řádky 10 a 11 – nastavení SRV záznamů pro správnou autokonfiguraci XMPP klientů a S2S spojení. Tyto záznamy nejsou nutné, ale přinejmenším záznam 11 je důležitý kvůli SAN v použitých SSL certifikátech (viz kap. SSL, šifrování, 4

záložní MX server přesahuje rozsah této práce, podle mého názoru není v typickém případu užití privátního cloudu nutný, zejména z důvodu předpokládaného objemu a frekvence příchozí pošty a faktu, že všechny slušné relay servery se několikrát pokusí o opakované doručení, takže občasné delší výpadky by neměly nijak vadit

25

certifikáty). Koncept privátního cloudu počítá s rozdělením jednotlivých služeb na subdomény, např. mail, im, cloud, nebo aktuálně neimplementované www. Pro každou službu je vytvořen validní SSL certifikát (vydaný zdarma službou Let’s Encrypt) s uvedenou doménou, jeden certifikát pro každou doménu. Podrobnosti jsou uvedeny v kapitole SSL, šifrování, certifikáty.

3.2.2

Síť

Síťová vrstva je součástí celé architektury, nicméně má-li být privátní cloud provozován na Internetu, je zároveň prakticky celá tato vrstva předem jasně definována a stanovena. Ze strany privátního cloudu neexistuje reálná možnost na této vrstvě architektury cokoliv ovlivnit tak, aby to nemělo žádný vliv na provoz a zároveň bylo přínosem pro soukromí dat - aby bylo možné privátní cloud nazývat cloudem, musí být přístupný prostřednictvím existující síťové infrastruktury třetích stran, které jsou vždy mimo kontrolu uživatele a v případě komerčních cloudů i nejméně z části mimo kontrolou poskytovatele těchto cloudů. Jediná možnost jak vyřešit zabezpečení dat putujících po sítích třetích stran je šifrování na vyšších vrstvách cloudové architektury, viz SSL, šifrování, certifikáty.

3.2.3

Server

Pro provoz webových aplikací lze v současnosti použít různé webhostingy, tj. cloudové služby poskytující operační a aplikační vrstvu nutnou pro provoz obvyklých webových aplikací. Nabídky webhostingů jsou však obvykle technologicky omezené a klient nemá nad operačním prostředím žádnou kontrolu. Privátní cloud v sobě integruje mnoho různých aplikací na různých operačních úrovních, nejedná se tedy jen o obyčejnou webovou aplikaci, ale o integrované prostředí, které je navenek směrem k uživateli reprezentováno webovou aplikací. Proto jsem se

26

rozhodl do architektury zahrnout i provoz vlastního serveru, kde lze zajistit vysokou míru kontroly nad operačním prostředím. I při zvolení této možnosti je však nutné dělat kompromisy. Server je pod kontrolou uživatele jen potud, pokud k němu má exkluzivní fyzický přístup. To znamená, že by jej uživatel musel mít doma5 . Díky rozmachu IoT se na trhu začínají objevovat zařízení, která tuto možnost uživateli dávají, např. různé minipočítače jako Rapsberry Pi6 či Intel NUC7 a privátní cloud na těchto zařízeních skutečně provozovat lze8 . Provoz na vlastním fyzickém serveru by ovšem pro uživatele znamenal nejen vstupní finanční zátěž v řádu jednotek až desítek tisíců Kč na pořízení samotného serveru, ale také nároky na připojení k Internetu s veřejnou a stabilní IP adresou (obvykle za příplatek u poskytovatele), vysokou rychlost a dostupnost připojení (ČR je na tom v tomto ohledu naštěstí velice dobře) a také nutnou odbornou průpravu s provozem takového serveru, např. instalace, zálohování, apod. Pokročilí uživatelé těchto možností jistě rádi využijí, ale na laického uživatele jsou tyto nároky nepřiměřené. Proto jsem se rozhodl privátní cloud navrhnout pro provoz na VPS. VPS je dle mého názoru rozumný kompromis mezi cenou pořízení a provozu, úrovní kontroly nad operačním prostředím a dostupnosti služeb “přidané hodnoty”, jako např. předinstalace operačního systému nebo pravidelné zálohování. Výkon samotného serveru není až tak důležitý, služby privátního cloudu nejsou příliš náročné a při předpokládaném objemu komunikace a dat by k provozu stačil i postarší notebook. V tabulce 3.1 je uvedeno orientační porovnání nákladů na provoz různých druhů serverů. Odhady cen vycházejí z ceníku služby SuperHosting9 , ceníku internetového obchodu Alza10 a z výše členských poplatků sdružení VPSFree11 . Ve sloupci fyzický server jsou ceny za pronájem resp. pořízeni a provoz fyzického serveru, pořizovací ceny fyzických 5 provoz privátního cloudu na skutečném fyzickém serveru umístěném v housingovém centru vůbec neuvažuji, náklady by byly nepřiměřené 6 https://www.raspberrypi.org/ 7 http://www.intel.com/content/www/us/en/nuc/overview.html 8 počítač Rapsberry Pi a podobné fungují na architektuře ARM, která není v současném instalátoru podporovaná, ale samotný koncept bude na této architektuře fungovat; do budoucna počítám se začleněním podpory pro tuto architekturu přímo do instalátoru 9 https://www.superhosting.cz/ (k 20.6.2016) 10 https://www.alza.cz (k 20.6.2016) 11 https://vpsfree.cz/ (k 20.6.2016)

27

i domácích serverů jsou odhadnuty na základě ceníku Alza.cz. Provozní náklady na VPS vycházejí z poplatků sdružení VPSFree, které je dle mého názoru nejlepší volbou pro provoz VPS. V provozních nákladech domácího serveru jsou zahrnuty odhady poplatků za veřejnou a stabilní IP adresu a nákladů na spotřebu elektrické energie. Tabulka 3.1: Porovnání nákladů na různé druhy serverů, zdroj: vlastní zpracování VPS

fyzický server

domácí server

0,-

0,- / 30 000,-

2 000,- – 6 000,-

provozní náklady

300,-

3000,- / 1000,-

200,-

předinstalovaný OS

ANO

NE

NE

zálohování

ANO

NE

NE

pořizovací náklady

Náklady uvedené v taublce 3.1 jsou kromě poplatku za doménu jediné náklady spojené s provozem privátního cloudu. Veškerý použitý software je dle definice[14] Open Source a tudíž bezplatný. Postup pořízení a zprovoznění serveru je mimo rámec této práce, nadále v textu předpokládám, že uživatel má k dispozici funkční server s předinstalovaným OS Debian 8 Jessie12 , veřejnou IP adresou, zná heslo uživatele root a má možnost přihlásit se k serveru jako root s autentiazí heslem pomocí SSH.

3.2.4

Operační systém

Volba operačního systému byla patrně nejjednodušší volbou ze všech. Operační systém fungující jako “podvozek” pro všechny ostatní prvky architektury musí být robustní, spolehlivý, snadno konfigurovatelný a musí být podporován použitými aplikacemi. Tyto požadavky dnes splňují všechny běžné serverové distribuce operačních systémů založených na Linuxu. Nejvíce zkušeností mám s provozem serverů s OS Debian a CentOS. Volba OS Debian 12

privátní cloud je samozřejmě možné provozovat i s jiným linuxovými OS, např. Ubuntu nebo CentOS, ale instalátor takovou konfiguraci v současnosti nepodporuje; úprava instalátoru není složitá a do budoucna s ní počítám

28

je čistě subjektivní – mám s touto distribucí nejvíce zkušeností a je mi z dostupných distribucí nejsympatičtější. Ostatní distribuce (CentOS, Ubuntu, atd.) by jistě byly stejně vhodnou volbou a v budoucnu počítám s rozšířením podpory instalátoru i o tyto distribuce.

3.2.5

Webserver

Wikipedia definuje webový server poměrně výstižně[15]: “Počítačový program, který je odpovědný za vyřizování požadavků HTTP od klientů (nejčastěji webových prohlížečů). Vyřízením požadavků se rozumí odeslání cíle specifikovaného URL (typicky webová stránka, ale též statický text, obrázek či jiný soubor). Webové stránky jsou obvykle dokumenty v jazyku HTML.”

Obrázek 3.3: Apache VS NGINX, zdroj: http://wikivs.com Privátní cloud je navenek tvořen webovými aplikacemi, ke svému provozu tudíž webserver potřebuje. Úkolem webserveru je zpracovat webovou stránku na straně serveru a co nejrychleji ji domluveným způsobem předat klientovi. Zdroj webové stránky může být soubor na disku serveru nebo výstup z nějaké serverové aplikace. Webserver nepředává klientovi jen webové stránky, ale také ostatní soubory, např. obrázky, skripty nutné pro správnou funkčnost webové stránky, apod. Webové aplikace nejčastěji podporují webservery Apache13 a Nginx14 . Tyto dvě aplikace slouží stejnému účelu, ale svou práci vykonávají diametrálně odlišným způsobem[16]. 13 14

http://apache.org http://nginx.org

29

Obrázek 3.4: Nginx: ukázka konfigurační šablony pro aplikaci Modoboa zobrazená v textovém editoru VIM, zdroj: vlastní zpracování

30

Stejně tak je odlišný zápis jejich konfigurace. Na obrázku 3.4 je vyobrazen ilustrační příklad konfigurace virtuálního serveru aplikace Nginx. Pro privátní cloud jsem zvolil webserver nginx a to ze tří hlavních důvodů: 1. nginx je méně náročný na systémové zdroje (privátní cloud je provozován na levných serverech nebo VPS s nižším výkonem) 2. nginx je rychlejší v poskytování HTTP obsahu, který má k dispozici 3. privátní cloud používá dvě rozhraní pro dynamický obsah - php-fpm a uwsgi a nginx se lépe hodí jako univerzální proxy [16] Webserver nginx je zároveň preferovaným webserverem aplikace Modoboa, kterou privátní cloud používá pro správu uživatelů a e-mailů15 .

3.2.6

php-fpm a uwsgi

Cloudová platforma je postavena na technologii PHP a aplikace pro správu uživatelů a e-mailu je naprogramována v jazyce Python. PHP i Python jsou tzv. skriptovací jazyky. To znamená, že zdrojový kód napsaný v těchto jazycích se obvykle nepřekládá do strojového kódu dané architektury, ale místo toho se předává tzv. interpretu. Interpret je aplikace, která zdrojový kód dokáže zpracovat a vykonat instrukce v něm napsané. Program napsaný ve skriptovacím jazyce je tedy “návod” pro jiný program, který podle daného návodu prování předepsané činnosti. V případě webových aplikací je výstupem interpretu zdrojový kód webové stránky, který je předán webserveru. Webserver následně tento kód stránky předá klientovi, jak bylo popsáno v předchozí podkapitole. php-fpm a uWSGI jsou nástroje zprostředkovávající komunikaci mezi webserverem a interpretem, nginx komunikuje s oběma nezávisle. php-fpm je součástí PHP 7, v současnosti nejnovější verze PHP. Přestože verze 7 je 15

https://github.com/modoboa/modoboa-installer

31

relativně mladá a málo podporovaná, rozhodl jsem se ji použít. Zejména proto, že výkonově předchozí verze PHP výrazně převyšuje[17] a cloudová platforma je na ni připravena [18]. Ukázka konfigurace instance php-fpm pro cloudovou platformu ownCloud s některými prvky optimalizace (volby php_value[]): [owncloud_instance] user = owncloud group = www-data listen = /run/php/owncloud_instance.sock listen.owner = www-data listen.group = www-data pm = dynamic pm.max_children = 5 pm.start_servers = 2 pm.min_spare_servers = 1 pm.max_spare_servers = 2 pm.max_requests = 300 slowlog = /var/log/php-$pool.log.slow request_slowlog_timeout = 30s request_terminate_timeout = 2d env[HOSTNAME] = $HOSTNAME env[PATH] = /usr/local/bin:/usr/bin:/bin env[TMP] = /tmp env[TMPDIR] = /tmp env[TEMP] = /tmp php_value[session.save_handler] = redis php_value[session.save_path] = /var/run/redis/redis.sock php_value[opcache.memory_consumption]=128 php_value[opcache.interned_strings_buffer]=8 php_value[opcache.max_accelerated_files]=4000 php_value[opcache.revalidate_freq]=60 32

php_value[opcache.fast_shutdown]=1 php_value[opcache.enable_cli]=1 php_value[opcache.enable]=1 K ukládání php session16 je použit systém Redis, který dokáže ukládat a poskytovat potřebná data výrazně rychleji než standardní řešení PHP pomocí textových souborů, neboť data drží primárně v operační paměti. Volba uWSGI byla ještě jednodušší - uWSGI a Green Unicorn jsou přímo podporovány aplikací Modoboa, která je v cloudu použita pro správu uživatelských účtů a e-mailů. Konfigurace uWSGI pro aplikaci Modoboa je velice jednoduchá: [uwsgi] uid = modoboa gid = www-data plugins = python home = /srv/app/modoboa/env chdir = /srv/app/modoboa/instance module = instance.wsgi:application master = true harakiri = 60 processes = 2 vhost = true no-default-app = true Green Unicorn v porovnání s uWSGI ve většině testů ztrácí17 a subjektivně se složitěji konfiguruje – výchozí balíčky distribuce Debian vyžadují pro každou instanci Green Unicorn dvojí configuraci: systémovou (v /etc/gunicorn.d/) a aplikační (konfigurační soubor v adresáři s aplikací). uWSGI vyžaduje pouze systémovou konfiguraci v /etc/uwsgi/ proto je subjektivně snažší jej konfigurovat a především 16

PHP Session je identifikátor konkrétního sezení uživatele v rámci webové aplikace, zajišťovaný na úrovni interpretu PHP; Sessions, nebo také “sezení” je způsob identifikace uživatele a detekce jeho souvislé činnosti v rámci konkrétního časového úseku a případně místa, sezení obvykle začíná přihlášením uživatele a končí buď jeho odhlášením, nebo po určité době nečinnosti 17 např. https://ivan-site.com/2012/09/benchmark-uwsgi-vs-gunicorn-for-async-workers/

33

udržovat.

3.2.7

Databáze

Relační SQL databáze je jedna z mnoha možností jak ukládat aplikační data. Většina prvků architektury vyžaduje datové úložiště a většina z nich zároveň jako datové úložiště umí používat SQL databázi. Z výkonového hlediska je nejvýhodnější používat jednu databázi (myšleno jednu instanci databázového serveru) a proto volba databáze znamenala zajištění kompatibility s používanými aplikacemi a v druhé řadě také zajištění použitelného výkonu. Z hlediska podpory databází má nejširší podporu databáze MySQL, viz tabulka 3.2, a proto byla volba databáze také jednoduchá. Tabulka 3.2: podpora různých SQL databází v použitých aplikacích, zdroj: vlastní zpracování MySQL

PostgreSQL

SQLite

Postfix

X

X

X

Dovecot

X

X

X

Modoboa

X

X

X

ownCloud

X

X

X

Amavis

X

Spamassassin

X

X

Prosody

X

X

X

Rainloop

X

X

X

V současnosti existují tři velké implementace MySQL databází: • původní MySQL, nyní vlastněná firmou Oracle • MariaDB, fork18 MySQL vyvíjen nezávisle, ale zachovávající kompatibilitu 18

pojem fork ve světě Open Source software znamená alternativní vývojovou větev software, udržovanou obvykle jiným subjektem, než původní software

34

s MySQL • Percona Server, další fork MySQL, zaměřený především na Enterprise zákazníky, též zachovávající kompatibilitu s MySQL Distribuce OS Debian podporuje pouze databázi MariaDB, neboť vývojáři nemají důvěru ve vývojový proces MySQL poté, co vývoj převzal Oracle[19]. Tuto nedůvěru s vývojáři sdílím, proto jsem původní MySQL vyloučil. Percona Server je z pohledu vývoje a kompatibility s MySQL konzervativnější[20], avšak zachovává si výkonostní náskok oproti MySQL především díky vlastní implementaci storage engine19 InnoDB, který nazývá XtraDB. Tento engine je výkonnější[21]. Způsob používání databáze jednotlivými komponentami architektury cloudu je velice jednoduchý, nejsou vyžadovány žádné speciální funkce a výkon databáze je vzhledem k očekávanému provozu vedlejší. Nejsnažší volbou by byla databáze MariaDB, ale v zájmu rozšiřování znalostí jsem se rozhodl vyzkoušet databázi Percona Server. Z pohledu aplikací není nutné žádných změn ani speciálních konfigurací, Percona Server je dle dosavadního testování zcela kompatibilní s MySQL a aplikace nevykazují žádné problémy související s databází. Konfigurace databáze je ponechána na výchozích parametrech s rozšířeným logováním pomalých dotazů (tzv. slow log). Pozorováním dlouhodobého provozu bude dále možné nastavení databáze optimalizovat směrem k vyššímu výkonu a případně i vyšší spolehlivosti, např. při nutnosti zavedení databázové replikace, došlo-li by k nasazení privátního cloudu ve větším rozsahu (např. komerčně nebo jako firemní informační systém).

3.2.8

Postfix

Postfix je jedním z nejrozšířenějších Open Source řešení e-mailového serveru a také jediným podporovaným mailserverem aplikace Modoboa[22]. 19

datbáze MySQL umožňuje zvolit způsob, jakým budou data uložena na disku, tyto způsoby (moduly) MySQL nazývá “storage engine” a jsou volitené na úrovni jednotlivých databází, v některých případech dokonce na úrovni tabulek

35

Ze všech služeb poskytovaných privátním cloudem je e-mail vůbec nejcitlivější a nejdůležitější. Chybně nakonfigurovaný e-mailový server může velice snadno zkolabovat pod náporem spamů a sám se ocitnout na seznamu nežádoucích serverů, což by negativně ovlivnilo možnost server reálně používat. I proto jsem se rozhodl v tomto případě neexperimentovat a použít robustní a podporované řešení, se kterým mám navíc zkušenosti. Zajímavé konfigurační parametry Postfixu vhodné či nutné pro použití v privátním cloudu: smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated check_recipient_access mysql:/srv/app/modoboa/postfix_maps/sql-maintain.cf mysql:/srv/app/modoboa/postfix_maps/sql-relay-recipient-verification.cf reject_unverified_recipient reject_unauth_destination reject_non_fqdn_sender reject_non_fqdn_recipient reject_non_fqdn_helo_hostname postscreen_access_list = permit_mynetworks postscreen_greet_banner = Welcome, please wait... postscreen_greet_action = enforce postscreen_pipelining_enable = no postscreen_non_smtp_command_enable = no postscreen_bare_newline_enable = no Nastavení

smtpd_recipient_restrictions

reflektuje

dvojí

roli

mailserveru,

a to MTA a MSA, kdy ve výchozím stavu se chová jako MTA, tedy běžný internetový mailserver, který přijímá a odesílá poštu jménem uživatelů, a nastavení smtpd_recipient_restrictions řídí způsob doručování pošty mimo domény

36

obsluhované tímto serverem. Konkrétně toto nastavení zajišťuje, že na “cizí” domény může e-mail zaslat pouze autentizovaný a autorizovaný uživatel, zatímco na domény “vlastní” může e-mail zaslat kdokoliv z Internetu. Nastavení postscreen jsou jednoduchá opatření proti spammerům, konkrétně se jedná o sadu pravidel aplikovatelných v brzkých fázích pokusu o doručení pošty, která jsou schopna odfiltrovat největší množství spamů bez dopadu na výkon serveru nebo dobu doručení pošty. Druhou úrovní ochrany je tzv. greylisting, který je v tomto případě vypnutý, neboť způsobuje průtahy v doručování pošty, což může být pro uživatele nežádoucí. Greylisting funguje na principu dočasného odmítnutí příjmu pošty. Legitimní mailservery se při dočasném odmítnutí pokusí zprávu doručit opakovaně, spammeři na to obvykle nemají čas ani prostředky a proto je tato kontrola poměrně efektivní z hlediska účinnosti a spolehlivosti, ale znamená, že prvních několik zpráv od legitimního serveru může být doručeno se zpožděním i několika hodin. Vzhledem k předpokládanému minimálnímu vytížení serveru (jednotky uživatelů a desítky, nanejvýš stovky zpráv denně) jsem se rozhodl tuto ochranu nezavést - věřím tomu, že vyšší vrstvy (Amavis a Spamassassin) si dokáží případné spamy odfiltrovat stejně efektivně a výhodou pro uživatele je, že nebude docházet ke zdržení v doručování. Nevýhodou je, že počet spamů může být o něco vyšší. Konkrétní čísla lze jen těžko odhadnout, ale dle empirického pozorování očekávám, že tato vyšší čísla se neprojeví negativně na uživatelské zkušenosti při používání privátního cloudu. Pokud by se ukázalo, že zpracování spamu ve vyšších vrstvách je natolik výkonově náročné, že výrazně ovlivňuje funkci celého cloudu (je stále nutné brát v úvahu, že privátní cloud může být provozován na nevýkonných domácích serverech), je samozřejmě možné tuto ochranu zapnout ručně. Instalátor v současnosti s možností pokročilé konfigurace nepočítá, ale vzhledem k použitým technologiím by v případě poptávky po této funkcionalitě nebyl problém ji doplnit a to včetně možnosti konfigurovat již nainstalovaný privátní cloud. Více podrobností je uvedeno v kapitole Instalátor privátního cloudu.

37

3.2.9

Spamassassin a Amavis

Tyto dvě aplikace slouží k zajištění analýzy e-mailových zpráv za účelem zjištění, zda se nejedná o SPAM. Přestože existuje více aplikací, které mohou tuto roli zastat, volba těchto dvou byla též jednoduchá – jedná se o jedinou kombinaci podporovanou aplikací Modoboa[22]. Amavis je nástroj pro přípravu e-mailových zpráv k analýze. Dokáže každou zprávu rozložit na konkrétní části (hlavičky, tělo zprávy, přílohy) a dokáže dokonce připravit k analýze i obsah příloh (např. v ZIP archivech). Spamassassin je pak nástroj, který provádí samotnou analýzu. Aplikace Modoboa komunikuje pouze s aplikací Amavis prostřednictvím databáze. Díky této aplikaci dokáže Modoba zajistit karanténu jednotlivých zpráv, pokud jsou označeny jako SPAM a může pak administrátorovi poskytnout možnost některé SPAMy zadržet dříve, než se dostanou k uživateli. Toho se využívá zejména v případech, kdy je v e-mailu detekován virus či jiný malware. Modoboa pak jednotlivým uživatelům poskytuje vlastní karantény, kam se mohou detekované SPAMy s nižší mírou škodlivosti dostat a ze kterých je pak uživatel může buď vyzvednout (pokud se tam dostaly omylem) nebo smazat, případně je předat administrátorovi k další analýze. Poslední úrovní klasifikace SPAMů je umisťování SPAMů do zvláštní složky ve schránce uživatele (zde se nejedná o karanténu - karanténa je prostor, který je od schránky uživatele zcela oddělený) a u těch nejméně závažných nebo nejméně jistých SPAMů dojde pouze o přidání slov “SPAM” do předmětu zprávy. Spamassassin je možné trénovat. Prostřednictvím karantény lze ručně zprávy označovat jako SPAM/HAM, a tím Spamassassinu dávat najevo, jak má v budoucnu podobné zprávy třídit. Podobně je možné trénovat Spamassassin na úrovni schránky uživatele – přesunutím zprávy do složky SPAM dojde k jejímu předání Spamassassinu, který se jí naučí. Ochrana proti SPAMu je velice individuální, proto není možné použít žádný univerzální 38

filtr a naopak je nutné naučit Spamassassin rozpoznávat konkrétní zprávy. Postupem času bude při správném učení Spamassassin ve své detekci přesnější, ale ze začátku lze očekávat vysokou míru chybných detekcí (jak pozitivních tak negativních). Proto také v prvních měsících používání doporučuji častěji kontrolovat karanténu.

3.2.10

Dovecot

Koncept doručování e-mailů je velice podobný klasické poště. Doručení e-mailu příjemci sestává ze dvou fází - fáze doručení do schránky příjemce, kterou zajišťuje poštovní úřad (či jiný doručovatel) a fáze vyzvednutí pošty ze schránky uživatelem. Odesílat poštu může každý a tato možnost se neváže na existenci nějaké poštovní schránky odesílatele. Stejně jako u papírové pošty – na obálku dopisu je možné napsat libovolnou adresu odesílatele a odeslat na přepážce jakékoliv pobočky pošty nebo prostřednictvím vhazovacích poštovních schránek. První fáze doručení e-mailu se děje prostřednictvím protokolu SMTP. Stejně jako u papírové pošty lze u e-mailu na obálku zprávy napsat cokoliv - libovolného příjemce, ale i libovolného odesílatele. SMTP protokol se stará o přijetí e-mailové zprávy od odesílatele a zajišťuje její doručení do schránky příjemce. Zde však role SMTP serveru (v případě privátního cloudu aplikace Postfix) končí. Pokud chce uživatel zprávu vyzvednout ze schránky, musí k tomu použít vhodný protokol. V případě privátního cloudu se jedná o běžný protokol IMAP zprostředkovaný aplikací Dovecot. Postfix předá příchozí poštu aplikaci Dovecot, která ji uloží do schránky na serveru a následně na vyžádání poskytne uživateli. Uživatel ke své schránce na serveru obvykle přistupuje prostřednictvím nějakého programu, klienta, např. Thunderbird, Outlook, iMail či jiné mobilní aplikace, nebo prostřednictvím webové aplikace, tzv. “webmailu” (Squirellmail, Horde, Rainloop, apod.) Schránka je těmto aplikacím zpřístupněna právě prostřednictvím protokolu IMAP a volba aplikace je svobodnou volbou uživatele. Druhá role aplikace Dovecot v privátním cloudu je poskytnutí autentizačního mechanismu SASL ostatním aplikacím. To znamená, že Dovecot je schopen číst databázi 39

uživatelů a na dotaz ostatních aplikací ověřit, zda se dotazovaný uživatel v této databázi nachází a zda odpovídá poskytnuté heslo. Tento mechanismus využívají přímo či nepřímo všechny ostatní aplikace a služby v privátním cloudu. Konfigurace aplikace Dovecot vychází z výchozího nastavení a neobsahuje žádné neobvyklé úpravy, pouze upřesnění a specifika pro konkrétní operační architekturu (např. umístění některých souborů, apod.)

3.2.11

SSL, šifrování, certifikáty

Součástí operační architektury je i šifrování datových přenosů. Všechny aplikace privátního cloudu, které komunikují s okolním světem, podporují při této komunikaci šifrování pomocí SSL resp. TLS. V některých případech je toto šifrování přímo vyžadováno (např. u webových aplikací dostupných prostřednictvím webserveru). Šifrování je u internetového provozu obvykle řešeno pomocí SSL certifikátů, které jsou součástí PKI. PKI je zjednodušeně řečeno mechanismus ověření identity protistrany pomocí certifikátu. Komunikační strana (v případě privátního cloudu server) si vytvoří vlastní privátní šifrovací klíč a žádost o certifikát se svými údaji a s veřejným šifrovacím klíčem20 . Účelem PKI je ověřit pravost těchto údajů. V případě privátního cloudu jsou jediné podstatné (a v certifikátu uvedené) údaje doménová jména jednotlivých služeb. Tuto žádost zašle Certifikační autoritě (obvykle komerční společnost), která údaje v žádosti ověří a pokud odpovídají skutečnosti, vystaví certifikát s těmito údaji, který podepíše. Od tohoto okamžiku každý, kdo důvěřuje Certifikační autoritě, může důvěřovat i serveru, který se prokazuje s tímto certifikátem21 . 20

princip privátního a veřejného klíče (a další aspekty počítačové i fyzické bezpečnosti) výborně popisuje Ross Anderson v kap. 5.2.5 knihy Security Engineering[23], která je navíc dostupná zdarma (http://www.cl.cam.ac.uk/~rja14/book.html) 21 přesněji řečeno, může důvěřovat tomu, že údaje v certifikátu jsou pravdivé, server svou příslušnost k certifikátu prokazuje tím, že použije privátní klíč, který je protějškem veřejného klíče v daném certifikátu

40

Ještě nedávno bylo jediným způsobem jak získat certifikát od důvěryhodné autority jeho zakoupení za částky v řádu desítek až stovek USD za rok. Toto pořízení certifikátu navíc u žádné mě známé autority nebylo automatizováno a bylo nutné certifikáty ručně ověřovat (tj. předat žádost o certifikát autoritě) a instalovat. Tato situace se změnila shodou náhod v době tvoření této práce, konkrétně v dubnu roku 2016, kdy byl spuštěn ostrý provoz automatizované certifikační autority Let’s Encrypt, která vydává certifikáty navíc zdarma[24]. Existence této autority zásadně změnila způsob, jakým bylo v privátním cloudu nutné zajišťovat certifikáty. Díky této autoritě je nyní možné certifikáty vytvářet a obnovovat zcela automatizovaně bez uživatelského zásahu, čehož v privátním cloudu extensivně využívám. Pro vytváření a správu certifikátů pomocí Let’s Encrypt jsem vytvořil jednoduchý nástroj, který nazývám lego-wrapper[25]. Tento nástroj využívá program lego[26] ke komunikaci se servery Let’s Encrypt, k vytváření žádostí o certifikáty a jejich doručení. Takto vytvořené certifikáty následně instaluje na určená místa v operačním systému, kde jsou přístupné aplikacím k použití. Nástroj lego-wrapper umožňuje automatickou správu certifikátů, tj. jejich vytváření a pravidelné obnovování, bez zásahu administrátora. V rámci konceptu privátního cloudu jsem se, i díky jednoduché a bezplatné dostupnosti certifikátů rozhodl jít cestou “pro každou službu vlastní certifikát” a v návaznosti na toto rozhodnutí i “pro každou službu vlastní (sub)doménu”. Důvodem tohoto rozhodnutí je zejména příprava na případné rozložení provozu služeb privátního cloudu na více serverů a také omezení nutnosti mít uvedeny všechny subdomény v jednom certifikátu - Let’s Encrypt totiž v současnosti neumožňuje vydat tzv. wildcard certifikát2223 . 22

u každého certifikátu je uvedeno pro jaké (sub)domény může být použit, speciální “wildcard” certifikát umožňuje použití na neomezeném počtu subdomén, aniž by tyto domény bylo nutné v certifikátu všechny vyjmenovat - použije se pouze zástupný symbol *, tedy tzv. “wildcard” 23 stav podpory: https://community.letsencrypt.org/t/please-support-wildcard-certificates/258

41

3.3

Aplikační architektura

V této kapitole popisuji aplikační vrstvu privátního cloudu, tedy jednotlivé aplikační komponenty, které dohromady vytváří funkční platformu samotného cloudu. Součástí aplikační architektury je zejména základ cloudové platformy (aplikace ownCloud) a databáze uživatelů a způsob práce s ní.

3.3.1

Uživatelská databáze

Obrázek 3.5: Zjednodušené schéma autentizačních prvků aplikační architektury, zdroj: vlastní zpracování Každý informační systém pracující s uživatelskými účty musí obsahovat nějakou formu 42

řídící uživatelské databáze, privátní cloud nevyjímaje. Řídící databáze uživatelů obvykle poskytuje data pro autentizační a autorizační mechanismy, jako např. SASL, Kerberos, PAM, apod. Databáze uživatelů v privátním cloudu má pouze autentizační roli, autorizaci řeší jednotlivé aplikace nezávisle. Pro správu uživatelské databáze jsem zvolil nástroj Modoboa. Autentizačních mechanismů je více. V současnosti jsou všechny autentizační požadavky vykonávané z aplikační vrstvy, s výjimkou aplikace Modoboa, řešeny na operační úrovni aplikací Dovecot a to prostřednictvím IMAP nebo SASL autentizace. Některé prvky operační vrstvy, mimo jiné i samotný Dovecot, používají k autentizaci přímo SQL databázi uživatelů, spravovanou aplikací Modoboa. Zjednodušené schéma aplikační autentizace je vidět na obrázku 3.5. Umístění a správa uživatelské databáze byla jednou z klíčových vlastností architektury privátního cloudu, kterou bylo nutno rozhodnout jako jeden z vůbec prvních kroků návrhu architektury. Od začátku jsem věděl, že jako autentizační mechanismus budou použity komponenty SASL a IMAP aplikace Dovecot, ale nevěděl jsem, z které databáze bude Dovecot čerpat uživatelské údaje. Možnosti byly v zásadě dvě: použít uživatelskou administraci a databázi platformy ownCloud, nebo použít externí nástroj spojený se správou e-mailových schránek, účtů a domén a následně jej pomocí nějakého mechanismu integrovat do platformy ownCloud. První možnost by byla uživatelsky jednodušší, ale znamenala by několik nevhodných kompromisů na straně konfigurace a správy e-mailů – ownCloud nezná koncept aliasů, přesměrování, domén a dalších funkcionalit potřebných k dynamické konfiguraci e-mailového serveru. Bylo by tedy nutné e-mailový server nakonfigurovat kompletně celý staticky během instalace bez možnosti další jednoduché uživatelské administrace přesahující přidání a odebírání uživatelů v rámci jedné domény, což by mimo jiné znamenalo např. nemožnost přesměrování e-mailů, absenci tzv. doménového koše24 24

Doménový koš je mechanismus univerzálního přesměrování e-mailu, kdy e-mail poslaný na jakoukoliv neexistující e-mailovou adresu na konkrétní doméně nebude zahozen, ale bude doručen do

43

nebo nemožnost provozovat e-mail pro více domén, případně poskytovat v rámci privátního cloudu volitelně pouze e-mailovou službu bez použití cloudové platformy. Druhá možnost znamenala udělat ústupek na straně jednoduchosti správy směrem k lepším možnostem uživatelské administrace a kompletní nezávislosti e-mailového subsystému. Po pečlivém zvážení obou možností jsem se rozhodl jít druhou cestou z důvodu zachování možnosti používat pouze e-mailový server bez cloudové platformy a zachování možnosti podrobnější konfigurace e-mailových služeb, které mohou požadovat zejména pokročilí uživatelé (např. doménový koš, virtuální domény a aliasy, apod.)

3.3.2

Modoboa

“Modoboa je plaforma pro konfiguraci a řízení e-mailového serveru prostřednictvím jednoduchého webového rozhraní. Součástí instalace jsou užitečné komponenty, jako například administrační panel, webmail nebo frontend k scanneru Amavis[27].” Modoboa není jedinou aplikací schopnou spravovat nastavení e-mailového serveru postaveného na běžné platformě Postfix + Dovecot + databáze a nebyla ani mou první volbou. V počátcích návrhu architektury tato aplikace vůbec nebyla v užším výběru. Prvotní výběr aplikací pro správu e-mailů se skládal z webových aplikací PostfixAdmin 25 a ViMbAdmin 26 . Základní funkční principy jsou u všech aplikací z výběru stejné - vytváří specifickou databázovou strukturu a udržují data v této struktuře obsažená. Tuto databázi pak pasivně využívají Postfix a Dovecot jako zdroj dat pro vlastní konfiguraci a jako uživatelskou databázi, jedná se tedy de-facto o formu řídící databáze. Postfixadmin je relativně stará aplikace, která se příliš nerozvíjí, nicméně je udržovaná. definované schránky – doménového koše. Tato možnost ve výchozím nastavení privátního cloudu není definována, ale lze ji snadno zprovoznit. 25 http://postfixadmin.sourceforge.net/ 26 http://www.vimbadmin.net/

44

Současná verze 2.3 je z roku 2009[28] s poslední údržbovou aktualizací z podzimu 2015. Uživatelské rozhraní je velice strohé a pro nezkušeného uživatele značně nepřehledné (obr. 3.6). Na druhou stranu je však aplikace léty prověřená, stabilní a funkční. PostfixAdmin je napsaný v jazyce PHP a stanovenou kompatibilitu má pouze s PHP verze 4 a 5[28]. Podpora PHP verze 7 není jasná.

Obrázek 3.6: Ukázka administračního rozhraní PostfixAdmin, zdroj: webová stránka http://postfixadmin.sourceforge.net/screenshots/ ViMbAdmin je novější alternativou PostfixAdminu s příjemnějším uživatelským rozhraním, která je navíc schopna “převzít” již existující databázi vytvořenou a spravovanou PostfixAdminem27 . Dokáže zastat všechny funkce PostfixAdminu a navíc přidává možnost uživatelům jednoduše měnit heslo a archivovat celé e-mailové schránky[29]. Podporuje PHP 5.4+, není jasné, zda podporuje i PHP 728 . Uživatelské rozhraní je přehlednější, jednodušší a odpovídá moderním trendům (viz obr 3.7). Přesto je však poměrně pokročilé a pro neznalého uživatele může být rozsah funkcionality matoucí. Aplikace Modoboa se mezi zvažované aplikace dostala náhodou. Oproti předchozím dvěma možnostem má ještě jednodušší uživatelské rozhraní (obr. 3.8) a především má navíc funkcionalitu nutnou pro jednoduchou správu SPAMů a integrovaný webmail, čímž velice snadno umožňuje provoz e-mailových služeb nezávisle na cloudové platformě. 27 28

https://github.com/opensolutions/ViMbAdmin/wiki/Migrate-from-Postfix-Admin https://github.com/opensolutions/ViMbAdmin/wiki/Installation

45

Obrázek 3.7: Ukázka administračního rozhraní ViMbAdmin, zdroj: vlastní zpracování Instalace a konfigurace aplikace Modoboa představovala výzvu, protože narozdíl od předchozích dvou variant je napsaná v jazyce Python, což znamená nutnost instalace a provozu druhého interpretu a spouštěcího rozhraní, uWSGI, popsaného v kapitole Operační architektura. V tabulce 3.3 je vidět porovnání jednotlivých aplikací z pohledu funkcionalit. Modoboa má sice nejvíce funkcionalit, bylo však nutné rozhodnout, zda tyto funkcionality vyvažují potřebu provozu dvou middlewarů (uWSGI a php-fpm). Konfigurace uWSGI je jednoduchá a negativní výkonový dopad se změřit nepodařilo. Nasazení aplikace Modoboa se však ukázalo jako velice problematické - bylo nutné ji nainstalovat a nakonfigurovat “ručně”, což kvůli mé minimální zkušenosti s Pythonem a aplikačním prostředím tohoto jazyka způsobilo komplikace, které mne v návrhu výrazně zdržely. I kvůli času investovanému do zprovoznění aplikace Modoboa jsem se nakonec rozhodl u ní zůstat. Aplikace má v současnosti jednu nepříjemnou chybu - nelze nastavit český jazyk29 . Tato chyba je sice již dle vývojářů odstraněna, avšak oprava ještě v době 29

https://github.com/modoboa/modoboa-webmail/issues/37

46

Obrázek 3.8: Ukázka administračního rozhraní Modoboa, zdroj: vlastní zpracování psaní této práce nebyla zpropagována do distribuované verze. Instalátor používá vždy nejnovější verzi z distribuce, je tedy velice pravděpodobné, že v budoucích instalacích již tato chyba nebude. Tabulka 3.3: srovnání funkcionalit aplikací pro správu mailů, zdroj: vlastní tvorba PostfixAdmin

ViMbAdmin

Modoboa

správa adres

X

X

X

správa aliasů

X

X

X

správa domén

X

X

X

kvóty

X

X

X

archivace

X

změna hesla

X

X

správa Amavis

X

webmail

X

PHP 7

?

?

Role aplikace Modoboa v privátním cloudu je dvojí. Především se jedná o ucelené a nezávislé řešení správy a používání 47 e-mailového serveru, včetně jednoduchého webmailu, a zároveň o administrační rozhraní uživatelské databáze, kterou používá celá cloudová platforma. Platí, že kdo má na serveru e-mailový účet, může (ale nemusí)

Java30 • XEP 124 a 206 (Bosh a XMPP over Bosh) – nutné pro integraci do platformy • XEP 198 (Stream management) – pro šetření baterie mobilních telefonů • XEP 160 (Best practices in handling offline messages) – pro správné předávání zpráv pomocí Facebook transportu (viz dále) • XEP 313 (Message Archive Management) – pro ukládání zpráv na serveru, vhodné zejména kvůli integraci Facebook transportu Tyto podmínky splňují bez dalšího 3 servery: Prosody, eJabberd a MongooseIM. Server MongooseIM je “zaměřen na rozsáhlé firemní instalace s více servery”[30] a tudíž je pro nasazení v privátním cloudu nevhodný. Volba mezi Prosody a eJabberd byla subjektivní. Oba servery by jistě splnily své úkoly srovnatelně dobře, nicméně podobně jako u předchozích voleb jsem se rozhodl na základě subjektivního pocitu z jednoduchosti instalace a konfigurace, kde podle mého názoru Prosody vyhrává. Instalátor momentálně umožňuje konfiguraci pouze pro jednu doménu, nicméně přidat další domény ručně je triviální a v budoucnu počítám rozšířením instalátoru i o tuto možnost.

3.3.4

ownCloud

Aplikace ownCloud je základem celé platformy privátního cloudu a jediná aplikace z celé architektury, se kterou bude uživatel při běžném provozu v přímé interakci. Celý koncept byl postaven na této aplikaci jako aplikaci platformní, tudíž původně vůbec nemělo smysl hledat alternativy. Aplikace ownCloud je privátní cloud a celý koncept privátního cloudu je postaven jako ekosystém pro podporu instalace, konfigurace 30

Java by bylo vedle Pythonu a PHP další běhové prostředí, které by muselo být na serveru nainstalované a spuštěné. Prostředí Java je specifické minimální systémovou integrací (tj. není možné efektivně využívat zdrojů operačního systému - Java si všechno “dělá sama”) a zvýšenými nároky především na operační paměť.

48

a provozu e-mailu, aplikace ownCloud a některých základních rozšíření běžným uživatelem bez hlubších IT znalostí. Tato premisa stále platí, nicméně kvůli nedávnému rozkolu vývojářů ownCloudu není vyloučené, že v budoucnu bude platforma migrovat na aplikaci nextCloud, která je čerstvým forkem ownCloudu31 vedená tvůrcem původního ownCloudu. Tento vývoj byl v době psaní této práce natolik čerstvý, že jsem se s ním v této práci dále nezabýval a dávám jej jen jako téma, které bude možná nutné řešit v budoucnu. Architektonicky je ownCloud běžnou webovou aplikací napsanou v jazyce PHP a celá operační i aplikační architektura privátního cloudu byla koncipována tak, aby této aplikaci poskytovala co možná nejefektivnější prostředí pro běh. ownCloud poskytuje udržované distribuční instalační balíčky, je tedy možné jej snadno nainstalovat a aktualizovat prostřednictvím standardních prostředků operačního systému. Platforma ownCloud poskytuje většinu cloudových služeb privátního cloudu, mezi které patří například správa a synchronizace kontaktů a kalendáře, synchronizace souborů, IM komunikace, webmail, fotogalerie a další. ownCloud je možné rozšířit mnoha oficiálními i neoficiálními aplikacemi a to velice jednoduchým způsobem, doslova “na klik” (dva kliky v případě neoficiálních, tzv. “experimentálních” aplikací). Mezi rozšiřující aplikace patří např. správa záložek, RSS agregátor, on-line tvorba dokumentů (podobně jako Google Docs), poznámky, správa hudby, propojení s dalšími cloudovými službami (Dropbox, Google Drive, atd.), správa hesel, kreslení obrázků a mnoho dalších. ownCloud používá primárně uživatelskou databázi aplikace Modoboa, nicméně umožňuje i zakládání “lokálních” účtů platných pouze pro aplikace ownCloud. Takto lokálně vytvořené účty umožňují omezené použití aplikací v rámci ownCloudu (např. synchronizace souborů nebo kalendáře), ale neumožňují použití ostatních služeb platformy, zejména e-mailu. Uživatelé těchto účtů navíc nemohou z praktických důvodů měnit své heslo – heslo jim musí být vytvořeno, přiděleno a případně změněno 31

http://karlitschek.de/2016/06/nextcloud/

49

výhradně administrátorem. Používání lokálních účtů nedoporučuji, ale rozhodl jsem se je nezakázat, protože věřím, že uživatel by neměl být ve svých rozhodnutích omezován a také nemohu vyloučit, že nějaký uživatel najde pro lokální účty kreativní využití.

3.4

Platforma privátního cloudu

Celý privátní cloud se stává cloudem* až po tom, co jej uživatel naplní svými daty, uživatelsky nakonfiguruje a začne jej používat. Platforma privátního cloudu uživateli “pouze” poskytuje prostor k realizaci vlastního cloudu, ale bez dat a uživatelské interakce je to jen platforma – místo a prostředky, kterými uživatel může stavět svůj vlastní, osobní, unikátní privátní cloud. Platformu privátního cloudu tvoří aplikace ownCloud a páteřní služby (e-mail, IM). Všechny tyto služby jsou dostupné prostřednictvím ownCloudu a u kterých to dává smysl i prostřednictvím externích aplikací (např. e-maily, IM, synchronizace souborů a adresářů, . . . ) Používání platformy je jednoduché a intuitivní (viz obr. 3.9). Přidaná hodnota platformy privátního cloudu spočívá v základní integraci několika služeb a aplikací, které při prosté instalaci ownCloudu nejsou k dispozici, jako např. IM nebo e-mail.

3.4.1

Základní služby platformy

Platforma poskytuje uživateli bezprostředně po instalaci následující základní služby. Pro ilustraci v následujících příkladech budu uvažovat, že si uživatel koupil doménu mujcloud.cz nakonfiguroval platformu pro tuto doménu. Před instalací uživatel zvolí jméno prvního uživatelského účtu platformy, který bude mít administrátorská oprávnění. Pro ilustraci budu předpokládat, že si uživatel zvolil jméno franta. Instalátor vytvoří uživatele [email protected] a uživatel bude pod

50

Obrázek 3.9: Ukázka webového rozhraní privátního cloudu s instalovanými aplikacemi, zdroj: vlastní zpracování tímto uživatelským jménem přistupovat ke všem službám cloudu. Heslo mu bude vygenerováno a zasláno na e-mail, který uvede při instalaci.

3.4.1.1

E-Mail a základní správa uživatelů

Základní službou platformy je kompletní e-mailový server postavený na běžné architektuře Postfix – Dovecot – databáze a spravovaný aplikací Modoboa. Veškeré e-mailové služby jsou poskytovány na servisní doméně mail.mujcloud.cz s tím, že v základní konfiguraci přijímá e-mail pouze pro doménu @mujcloud.cz a bezprostředně po instalaci bude existovat pouze jedna e-mailová schránka ([email protected]) a pro ni dva aliasy: [email protected] nutný pro provoz e-mailového serveru a [email protected] pro servisní zprávy spamového filtru. Po správném nastavení MX záznamů může e-mailový server zpracovávat poštu pro libovolnou doménu, je pouze nutné tuto doménu nastavit v administraci. Pro každou doménu je možné nastavit doménový koš. Počet domén a uživatelských účtů je omezen 51

jen kapacitou serveru. Jednotky domén a desítky účtů by neměly činit problém ani nevýkonnému domácímu serveru. Všechny e-mailové schránky jsou uživatelům dostupné prostřednictvím protokolu IMAP (včetně šifrování) a každý slušný e-mailový program tento protokol umí používat. Mezi “slušné” programy podle předchozí věty patří mimo jiné Thunderbird, iMail, Outlook Express nebo e-mailový klient v prakticky každém chytrém mobilním telefonu. Pro Android doporučuji aplikaci K-9. IMAP je poskytován na standardních portech na doméně mail.mujcloud.cz. Přistupovat lze i přes ostatní (sub)domény, ovšem v takovém případě budou klientské aplikace s největší pravděpodobností hlásit chybu SSL šifrování, neboť IMAP protokol v šifrované verzi využívá certifikát vystavený pro doménu mail.mujcloud.cz. Podporováno je šifrování SSL na portu 993 i TLS (formou STARTTLS) na portu 143.

Obrázek 3.10: Ukázka nastavení e-mailu v mobilní aplikaci K-9, zdroj: vlastní zpracování E-mailový server poskytuje autentizovaným uživatelům i služby odesílání pošty prostřednictvím SMTP, opět na standardních MSA portech s šifrováním SSL (port 465) i TLS (formou STARTTLS) na portu 587. MSA na portu 25 podporováno není. Na obr. 3.10 je vyobrazena ukázka možnosti konfigurace mobilní e-mailové aplikace K-9. Obdobně lze nakonfigurovat i ostatní e-mailové aplikace a programy. 52

K e-mailové schránce lze přistupovat také prostřednictvím webmailu a to buď pomocí jednoduchého rozhraní přímo integrovaného do administračního rozhraní Modoboa nebo pomocí webmailové aplikace Rainloop integrované do ownCloudu.

Obrázek 3.11: Ukázka webmailové aplikace Rainloop integrované do prostředí ownCloud, zdroj: vlastní zpracování ownCloud obsahuje vlastního webmailového klienta, ale ten není dle mého názoru ještě dostatečně vyvinutý a chybí mu některé základní funkce, které by běžný uživatel mohl od cloudového webmailu vyžadovat (např. filtry, označování SPAMu, apod.) Rozhodl jsem se proto v rámci platformy nainstalovat webmailovou aplikaci Rainloop32 a zajistit její bezproblémovou integraci do ownCloudu. Pokud s touto aplikací nebude uživatel spokojen, má možnost nainstalovat i původní aplikaci ownCloudu.

3.4.1.2

Rainloop webmail

Aplikace Rainloop je samostatným projektem a je možné ji provozovat nezávisle na ownCloudu. Zároveň však umožňuje určitou míru integrace s tímto prostředím a toho jsem se rozhodl využít (obr. 3.11). Bohužel i přes pokročilou míru integrace je vizuálně 32

http://www.rainloop.net

53

i koncepčně zřejmé, že Rainloop je externí aplikace a některé integrační kroky je stále nutné provést ručně. V rámci instalátoru se mi ovšem tyto ruční kroky podařilo zredukovat na jeden jediný - nastavení propojení s uživatelským adresářem kontaktů. Postup nastavení propojení kontaktů aplikace Rainloop s cloudem je naznčen na obr. 3.12. Nejprve je nutné v aplikaci Kontakty zjistit synchronizační adresu a tuto adresu zkopírovat do konfigurace aplikace Rainloop. Uživatelské jméno a heslo je stejné, jako přihlašovací údaje do cloudu a je nutné je vyplnit. E-mailový server funguje zároveň jako základní uživatelská databáze pro celou platformu a je to jediné místo, kde lze změnit uživatelské heslo a přidávat a odebírat uživatelské účty33 . Administrace e-mailového serveru a uživatelských účtů je dostupná na adrese https://mail.mujcloud.cz.

3.4.1.3

IM a Facebook messenger

Platforma poskytuje standardní XMPP server, který umožňuje decentralizovanou komunikaci formou IM s jakýmkoliv jiným uživatelem jakéhokoliv jiného XMPP serveru připojeného k Internetu. Dříve by bylo pomocí této služby možné komunikovat přímo i s uživateli Google Talk a Facebooku, ale tyto společnosti podporu XMPP ukončily, nicméně např. s Facebookem i s jinými sítěmi mimo XMPP lze komunikovat prostřednictvím tzv. transportů, viz dále. Komunikace mezi uživateli platformy je možná buď pomocí webové aplikace v rámci ownCloudu nebo pomocí externích klientů. Mezi nejznámější patří PSI/PSI+ (Windows, Linux, OSX), Adium (OSX), Gajim (Linux) nebo Conversations (Android). Na obr.2.2 je vidět webový klient a Gajim. Nastavení serveru je standardní, každý klient by měl být schopný po zadání správného uživatelského jména (např. [email protected]) zjistit všechna potřebná nastavení sám. V poslední fázi psaní práce přišel Facebook s novinkou – zakázal používání webového 33 uživatelské účty lze ve skutečnosti vytvářet na dvou místech, druhé místo je samotná aplikace ownCloud, ale tam vytvořené účty jsou z hlediska platformy omezené, viz předchozí kapitola ownCloud

54

Obrázek 3.12: Ruční nastavení propojení aplikace Rainloop s cloudovou aplikací Kontakty, zdroj: vlastní zpracování

55

rozhraní pro zprávy z mobilních telefonů a nahradil je odkazem na instalaci aplikace Messenger. Mnoho uživatelů v mém okolí tento krok odsoudilo a hledalo možnost, jak instalaci aplikace Messenger obejít. Seznam oprávnění aplikace Messenger v OS Android je z pohledu ochrany soukromí děsivý[31]: * Identita vyhledávání účtů v zařízení čtení vaší vlastní vizitky přidávání nebo odebírání účtů * Kontakty vyhledávání účtů v zařízení čtení kontaktů úprava kontaktů * Poloha přesná poloha (pomocí GPS a sítě) přibližná poloha (pomocí sítě) * SMS úprava textových zpráv (SMS nebo MMS) příjem textových zpráv (SMS) odesílání zpráv SMS čtení textových zpráv (SMS nebo MMS) příjem textových zpráv (MMS) * Telefon čtení stavu a identity telefonu čtení seznamu hovorů přímé volání na telefonní čísla přesměrování odchozích hovorů * Fotky/média/soubory úprava nebo mazání obsahu v úložišti USB čtení obsahu v úložišti USB * Úložiště úprava nebo mazání obsahu v úložišti USB

56

čtení obsahu v úložišti USB * Fotoaparát pořizování fotografií a videí * Mikrofon nahrávání zvuku * Informace o připojení Wi-Fi zobrazení připojení Wi-Fi * ID zařízení a informace o hovorech čtení stavu a identity telefonu * Jiné přijímat data z internetu stahování souborů bez oznámení ovládání vibrací spuštění při startu vykreslení přes další aplikace párování se zařízeními Bluetooth odeslání trvalého vysílání vytváření účtů a nastavení hesel změna připojení k síti zabránění přechodu zařízení do režimu spánku instalace zástupce čtení statistických údajů o baterii čtení nastavení synchronizace vypnutí nebo zapnutí synchronizace čtení konfigurace služeb Google zobrazování síťových připojení změna nastavení zvuku úplný přístup k síti Rozhodl jsem se tedy ještě na poslední chvíli do privátního cloudu integrovat podporu pro komunikaci s přáteli na Facebooku. Tato podpora je sice poněkud neuhlazená, ale svůj účel splní: síť XMPP podporuje funkci tzv. “transportů”, což jsou speciální služby

57

konkrétních serverů, které mohou zprostředkovat např. různé informace nebo třeba propojení s jinou komunikační sítí (ICQ, Skype, nebo třeba Facebook). Do operační architektury jsem přidal “Facebook transport”, který je možné připojit z libovolného klienta (bohužel webový klient v ownCloudu přidání transportu neumožňuje, uživatel musí použít nějakou aplikaci, např. Gajim). V IM klientovi se stačí pouze registrovat na transportu facebook.im.mujcloud.cz, zadat uživatelské jméno a heslo pro Facebook (heslo bude uloženo na serveru!) a transport zajistí konverzi kontaktů a předávání zpráv. Uživatelovi facebookoví přátelé se objeví v seznamu uživatelů stejně, jako kteříkoliv jiní uživatelé, které si uživatel do svého seznamu přidá a může s nimi následně přímo komunikovat prostřednictvím klientské aplikace na počítači, v mobilu nebo prostřednictvím webového rozhraní úplně stejně, jako s jinými uživateli.

3.4.1.4

Datové úložiště a synchronizace souborů

ownCloud poskytuje službu úschovy a synchronizace dat podobně, jako např. Dropbox. Existuje desktopová i mobilní aplikace34 , kterou lze pro tuto synchronizaci použít. Desktopová aplikace je zdarma a její použití je jednoduché. Po správném nastavení zajišťuje kontinuální synchronizaci lokálních a vzdálených dat při změnách na libovolné straně s tím, že jako “centrální” úložiště se považuje cloud a všechny aplikace synchronizují svá data pouze s cloudem a nikoliv mezi sebou navzájem. Mobilní aplikace je k dispozici na všech běžných obchodech s mobilními aplikacemi (AppStore i Google Play), ale je placená. Nicméně tato aplikace je také Open Source a dá se, přinejmenším do telefonu s OS Android, nainstalovat i zdarma (legálně)35 . V aplikaci ve verzi pro OS Android lze nastavit užitečnou funkci okamžité synchronizace pořízených fotografií (obr. 3.13), které zajistí, že jakákoliv pořízená fotografie bude při nejbližší příležitosti nahrána na cloud. Nemůže se tedy například stát, že by uživatel o fotografie přišel, když ztratí telefon nebo se mu poškodí SD karta. Lze zvolit, zda budou fotografie nahrány až když bude k dispozici WiFi připojení, nebo zda budou nahrávány pomocí mobilní datové sítě (a tudíž s dopadem na přenesená data). 34 35

https://owncloud.org/install/#install-clients https://f-droid.org/repository/browse/?fdid=com.owncloud.android

58

Obrázek 3.13: Ukázka nastavení okamžitého nahrávání fotek z mobilu do cloudu, zdroj: vlastní zpracování Další zajímavou funkcí je možnost sdílení souborů v rámci cloudu i s okolním světem – u každého souboru nebo složky má uživatel možnost je veřejně sdílet (volitelně s ochranou heslem) podobným způsobem, jako např. v Dropboxu nebo Google Drive (viz obr. 3.14). U sdílených dat je dokonce možné nastavit dobu trvání sdílení a zda mohou návštěvníci data měnit (např. nahrávat další soubory, apod.) Součástí správy souborů je i jednoduchý textový editor (nikoliv textový procesor).

3.4.1.5

Galerie

ownCloud umožňuje z nahraných obrázků automaticky tvořit obrázkové galerie. Každá složka s obrázky se automaticky stává galerií, je-li prohlížena prostřednictvím aplikace Galerie. Galerie lze snadno tvořit vytvářením složek a přesouvání fotografií a obrázků a je možné je sdílet stejně snadno, jako soubory a složky (obr. 3.15).

59

Obrázek 3.14: Ukázka možností sdílení složky Photos s ostatními uživateli a s veřejností, zdroj: vlastní zpracování

Obrázek 3.15: Ukázka galerie a možnosti sdílení galerie, zdroj: vlastní zpracování 60

3.4.2

Doporučené rozšíření služeb platformy

Výše uvedené služby jsou dostupné ve výchozí instalaci. Další služby je možné v ownCloudu aktivovat prostřednictvím správy aplikací (tlačítko “+ Aplikace” na obr. 3.9 – tuto volbu má k dispozici pouze administrátor cloudu). Doporučuji do cloudu přidat ještě nejméně oficiální či “potvrzené” (“approved”) aplikace Calendar, Contacts. Další zajímavé aplikace jsou Documents, Tasks, Notes a mnoho dalších. Těmi se ale v této práci již zabývat nebudu.

3.4.2.1

Kontakty a kalendář

Rozšířené služby Contacts a Calendar do cloudu přidávají možnost udržovat, sdílet a synchronizovat adresáře kontaktů (obr. 2.3) a uživatelské kalendáře (obr. 2.4). Tyto dvě aplikace jsou dle mého názoru jedním z nejzajímavějších přínosů privátního cloudu. Umožňují totiž synchronizaci kontaktů a kalendáře s chytrým mobilním telefonem a dalšími zařízeními. Synchronizace probíhá pomocí technologie CardDAV resp. CalDAV, které jsou přímo integrovány v nativních aplikacích iOS a lze je používat i s aplikacemi OS Android, kde je však před tím nutné nainstalovat ještě middleware, neboť aplikace v OS Android obvykle přímo *DAV protokoly neumí používat. Několik aplikací pro CardDAV a CalDAV je dostupných v obchodě Google Play, mým doporučením je Open Source aplikace DAVdroid36 , která je dostupná zdarma i mimo Google Play. Při konfiguraci aplikace DAVdroid je nutné pamatovat, že cloudová platforma je spuštěna na doméně cloud.mujcloud.cz a ne mujcloud.cz přesto, že uživatelská jména obsahují jen holou doménu ([email protected]), viz obr. 3.16. V obrázku je dále vidět příklad výběru kalendářů a adresářů ke sdílení (v cloudu jich uživatel může mít víc) a v poslední části je vidět výsledek synchronizovaného kalendáře (srov. s obr. 2.4). Synchronizace je obousměrná, tj, změny v telefonu (kontakty i kalendář) se přenesou do cloudu a naopak. Kalendář a kontakty je tedy možné plnohodnotně 36

https://davdroid.bitfire.at/

61

využívat pomocí všech dostupných prostředků. Zároveň nehrozí, že by uživatel přišel o cenné kontakty v případě, že by telefon ztratil nebo rozbil.

Obrázek 3.16: Ukázka nastavení aplikace DAVdroid a kalendáře, zdroj: vlastní tvorba

3.5

Instalátor privátního cloudu

Instalátor je patrně největším přínosem této práce. Jedná se o sadu různých nástrojů, skriptů a konfigurace, která umožňuje konzistentní, replikovatelnou a univerzálně nasaditelnou instalaci privátního cloudu na libovolný kompatibilní server. Instalátor není jen obyčejnou sadou skriptů a konfigurace – kompletní konfigurace je postavena na konceptu “Infrastructure As Code”[32] a obsahuje necelých 7000 řádků kódu. Celá infrastruktura je vytvářena a konfigurována pomocí nástroje Ansible37 . Instalátor se skládá z několika komponent: • kód infrastruktury – sada kódů zpracovávána Ansible • Ansible – součástí instalátoru je i kompletní nástroj Ansible38 37 38

https://www.ansible.com/ Ansible je Open Source nástroj, je tedy legální jej kopírovat a distribuovat. Pro tuto variantu jsem

62

• podpůrné skripty – konfigurační skripty pro některé složitější operace a pro přípravu a nastartování samotné instalace • linuxový instalátor – jednoduchý vícekrokový dialogový instalátor (obr. 3.17) • Windows instalátor – webová stránka s aktivními prvky, nejjednodušší způsob vytvoření aktivního dialogu ve Windows (obr. 3.18)

Obrázek 3.17: Instalátor privátního cloudu pro Linux, zdroj: vlastní tvorba Pro instalaci a konfiguraci privátního cloudu uživatel potřebuje pouze linuxový nebo Windows instalátor. Ostatní komponenty budou staženy z webových stránek projektu http://dipl.jakubfiser.cz/files, kde je možné také všechny komponenty instalátoru stáhnout ručně a prohlédnout, případně upravit. Linuxový instalátor je shellový skript a stáhnout jej lze na adrese následujcí adrese: http://dipl.jakubfiser.cz/files/linux_installer.sh. Stačí jej pouze spustit. Windows instalátor obsahuje více komponent - aktivní webovou stránku a aplikaci se rozhodl především kvůli zajištění kompatibility – Ansible prochází neustálým vývojem a instalační kód je otestován jen s jednou konkrétní verzí, která je k němu v distribuci “přibalena”. Kdyby byla použita aktuální verze, mohlo by se stát, že by nebyla s kódem kompatibilní.

63

Obrázek 3.18: Instalátor privátního cloudu pro Windows, zdroj: vlastní tvorba 64

KiTTY39 – SSH klienta, který instalátoru zprostředkuje SSH přístup k serveru (Windows, narozdíl od linuxových systémů, obvykle neobsahuje standardního SSH klienta). U Windows instalátoru je při prvním spuštění nutné ještě potvrdit bezpečnostní varování o neznámém klíči serveru (obr. 3.19). To je způsobené tím, že při prvním spuštění aplikace KiTTY nemá žádné informace o serveru, na který se připojuje a uživatel musí ručně potvrdit, že informace jsou správné. Toto chování bohužel nejde nijak jednoduše obejít a uživatel obvykle (zejména u VPS) ani nemá možnost tyto informace předem jednoduše zjistit.

Obrázek 3.19: Bezpečnostní varováni, které je nutné odsouhlasit, zdroj: vlastní tvorba Po spuštění instalace se samotná instalace přesune na pozadí a instalátor umožní uživateli buď zavřít okno, nebo se k probíhající instalaci připojit, aby mohla být uživatelem pozorována. V průběhu instalace je na tento “pozorovací” terminál vypsáno obrovské množství informací, přibližně 15000 řádků. Většinu informací tvoří výstupní záznamy (tzv. “log”) průběhu aplikace Ansible. K probíhající instalaci je možné se připojit i později po uzavření instalátoru - stačí pouze zvolit možnost “Připojit k instalaci”. Instalace na serveru od VPSFree trvá přibližně 15 minut, na jiných serverech se rychlost může lišit. V rychlosti instalace 39

http://www.9bis.net/kitty/

65

hraje roli výkon serveru ale i rychlost, jakou je server připojen k Internetu – objem stažených dat je v řádu stovek MB až jednotek GB a nedá se předem přesně odhadnout, neboť není předem známo, kolik balíků distribuce operačního systému bude nutné nainstalovat a případně aktualizovat. Po ukončení instalace bude uživateli na konfigurační e-mail odeslána zpráva obsahující informace o nově nainstalovaném privátním cloudu, především pak vygenerované heslo. Na nově vytvořenou e-mailovou adresu uživatele v cloudu bude odeslána stejná zpráva a navíc ještě zpráva s nově vygenerovaným heslem uživatele root. V případě, že během instalace dojde k chybě, udělá instalátor vše pro to, aby uživatele o této chybě v rámci možností informoval. Dojde-li k chybě v brzkých fázích instalace, bude uživateli informace předána přímo instalátorem, v pozdějších fázích po zprovoznění e-mailového subsystému bude uživateli poslána zpráva na konfigurační e-mail. K tomuto účelu je v brzkých fázích instalace konfigurován jednoduchý e-mailový subsystém, který je následně během instalace nahrazen robustní aplikací Postfix. Vzhledem k tomu, že e-mailové zprávy odcházejí z čerstvě nakonfigurovaného serveru automatizovanými prostředky, je bohužel možné, že tyto zprávy budou označeny jako SPAM. Uživateli proto doporučuji zkontrolovat po cca 15 – 20 minutách i složky se SPAMem. Po spuštění instalace již není ze strany uživatele v případě bezchybného průběhu třeba žádných zásahů. V případě, že dojde k chybě, je však nepravděpodobné, že by ji uživatel byl schopen sám opravit. V takovém případě doporučuji uživatelům zaslat informaci o chybě na e-mailovou adresu [email protected], aby mohla být analyzována a instalátor patřičně upraven. Po ukončení instalace je privátní cloud připraven k použití.

66

4. Závěr Cílem práce bylo navrhnout operační a aplikační architekturu privátního cloudu. Tohoto cíle bylo dle mého názoru dosaženo úspěšně. Vznikla operační a aplikační architektura, která podporuje a zajišťuje běh cloudové platformy, na které může i nezkušený uživatel stavět jednoduchý privátní cloud. Zároveň vznikly nástroje umožňující stejnému nezkušenému uživateli zprovoznit tuto architekturu poměrně jednoduše na vlastním serveru a za minimální náklady. Největším přínosem této práce je dle mého názoru poskytnutí možnosti kompletní instalace a provozu poměrně robustní a složité platformy i méně zkušeným uživatelům, kteří by jinak neměli reálnou a finančně dostupnou možnost přesunout své cloudové aktivity k důvěryhodnějším poskytovatelům cloudových služeb. Platforma cloudu je otevřená ve všech smyslech tohoto slova: všechny použité komponenty jsou Open Source a platformu je možné libovolně rozšiřovat o existující aplikace i o případné budoucí, nově vytvořené aplikace. Během práce jsem se naučil nové věci, zejména pak využití konceptu “Infrastructure as Code” a práci s nástrojem Ansible. Dále jsem se naučil konfigurovat a nasazovat webové aplikace napsané v jazyce Python, se kterými jsem dříve neměl žádné zkušenosti. Zopakoval a utvrdil jsem si také znalosti potřebné k úspěšné konfiguraci e-mailového serveru s (pro mne) novými koncepty, které dávají více kontroly běžnému uživateli v roli administrátora (např. správa karantény SPAMů či správa uživatelů) a zlepšil jsem se v projektovém (sebe)řízení z použitím agilních metod.

67

Všechny problémy, na které jsem během tvorby narazil, se ukázaly jako řešitelné, ale ne všechny jsem měl možnost vyřešit. Prostor ke zlepšení do budoucna vidím zejména v těchto oblastech: • umožnit v instalátoru volitelnou podrobnější konfiguraci a rekonfiguraci bez nutnosti zasahovat ručně přímo do konfigurace serveru (byť tyto zásahy jsou často triviální) • podporovat provoz v rozsáhlejším nasazení na více serverech (např. komerční či firemní nasazení, high availabilty, replikace, load balancing) • zvýšit míru automatizace v některých nastaveních (např. rozšíření výchozích cloudových aplikací o Kontakty a Kalendář) • přidat do operační architektury autoritativní DNS server a umožnit uživateli automatizaci správy DNS záznamů a: – vylepšit nastavení a zabezpečení e-mailového serveru o SPF a DKIM – vylepšit obecnou bezpečnost pomocí DANE • vylepšit práci se SPAMy a zajistit ještě lepší integraci aplikace Rainloop • rozšířit kompatibilitu instalátoru o další linuxové distribuce (např. CentOS, Ubuntu) a výpočetní architektury (ARM, zejména Rapsberry Pi) • umožnit konfiguraci jednotlivých subdomén a přidat možnost konfigurace provozu na více nezávislých doménách • vytvořit záznamy /.well-known/ pro automatickou konfiguraci služeb[33] • zajistit kompatibilitu a případně možnost migrace na nextCloud v případě, že se ownCloud ukáže jako problematická platforma nebo nextCloud jako výrazně lepší platforma • přidat do aplikační architektury CMS systém, vizuální website builder a/nebo blogovací platformu (např. Drupal, BuilderEngine resp. Wordpress) • vytvořit rozsáhlejší manuál a projektové webové stránky pro podporu uživatelů 68

• vytvořit instalátor s jednotným a konzistentním vzhledem a použitím pro Windows i Linux • vytvořit podrobnou technickou dokumentaci a uživatelský manuál

69

5. Seznam zkratek ARM architektura procesorů zaměřená na nízkou energetickou náročnost – většina chytrých mobilních telefonů je postavena na této architektuře BBS Bulletin Board System, předchůdce dnešních “internetových portálů” CalDAV webový protokol zajišťující přenos a synchronizaci kalendářů CardDAV webový protokol zajišťující přenos a synchronizaci adresářových kontaktů CMS Content Management System – webová aplikace určená k tvorbě obsahu webových stránek DNS Domain Name System – systém přidělování, provozu a kontroly internetových doménových jmen DSL Digital Subscriber Line, tzv. “pevná linka” HTML HyperText Markup Language – jazyk pro psaní webových stránek a strukturovaných dokumentů ISDN Integrated Services Digital Network, mezikrok mezi dial-up a DSL ICQ “I Seek You” – starší IM protokol a aplikace IM Instant Messaging – obecně on-line komunikace v reálném čase IMAP Internet Mail Access Protocol – protokol zajišťující dostupnost e-mailové schrány prostřednictvím různých programů (např. Thunderbird, Outlook Express či různé aplikace v mobilních telefonech) IRC Internet Relay Chat, způsob hromadné on-line komunikace IT Informační technologie – souhrnný název pro znalosti a technologie v oblasti výpočetní techniky MP3 MPEG Layer 3, ztrátový kompresní formát pro zvuková data MSA Mail Submission Agent – serverová aplikace/služba umožňující klientům

70

odesílání e-mailových zpráv prostřednictvím protokolu SMTP MTA Mail Transfer Agent – serverová aplikace/služba zajišťující předání e-mailových zpráv přijatých prostřednictvím MSA na servery příjemců prostřednictvím protokolu SMTP NIST National Institute of Standards and Technology, protějšek ÚNMZ OS Operační systém PIM Personal Information Management S2S Server-to-server – zkratka označující situaci či konfiguraci, která se týká komunikace mezi dvěma servery mimo (přímou) kontrolu uživatele SAN subjectAltName – parametr SSL certifikátu označující jedno z možných jmen, pod kterými může držitel certifikátu vystupovat SASL Simple Authentication and Security Layer – mechanismus autentizace uživatele v prostředí klient/server SMTP Simple Mail Transfer Protocol – protokol pro předávání e-mailových zpráv ve směru od odesílatele do schránky příjemců SPAM Nevyžádaná pošta (e-mail) SSH Secure Shell – mechanismus vzdáleného přístupu k OS na serveru (Linux a příbuzné OS) SSL Secure Socket Layer – zkratka označující rodinu protokolů a nástrojů pro šifrovanou komunikaci, v dnešní době je tato zkratka mírně zavádějící, neboť v sobě často zahrnuje i pojem TLS TLS Transport Layer Security – modernější náhrada SSL fungující na nižších síťových vrstvách, často je nesprávně zahrnována pod pojem SSL URL, URI Uniform Resource Locator / Identifier – identifikátor služby či zdroje dostupného pomocí počítače, nejčastěji používaný k přístupu k internetovým zdrojům ÚNMZ Úřad pro technickou normalizaci, metrologii a státní zkušebnictví VPS Virtual Private Server – virtuální server s běžnými vlastnostmi serveru reálného WebDAV webový protokol zajišťující přenos a synchronizaci souborů dat XMPP Extensible Messaging and Presence Protocol – otevřený IM protokol

71

Seznam tabulek 3.1

Porovnání nákladů na různé druhy serverů, zdroj: vlastní zpracování

.

28

3.2

podpora různých SQL databází v použitých aplikacích, zdroj: vlastní . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

34

srovnání funkcionalit aplikací pro správu mailů, zdroj: vlastní tvorba .

47

zpracování 3.3

72

Seznam obrázků 2.1

Ukázka hromadné komunikace prostřednictvím IRC, zdroj: vlastní zpracování . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2

12

Ukázka individuální komunikace prostřednictvím decentralizovaného protokolu XMPP, zdroj: vlastní zpracování . . . . . . . . . . . . . . . .

13

2.3

Ukázka PIM aplikace “Kontakty”, zdroj: vlastní zpracování . . . . . . .

15

2.4

Ukázka PIM aplikace “Kalendář”, zdroj: vlastní zpracování . . . . . . .

15

2.5

Porovnání náhledů obchodních podmínek a podmínek zpracování osobních údajů největších hráčů na IT trhu, zdroj: vlastní zpracování .

19

3.1

Zjednodušené schéma operační architektury, zdroj: vlastní zpracování .

24

3.2

Ukázka nastavení DNS záznamů pro provoz privátního cloudu na doméně diplomka.jakubfiser.cz ve webovém rozhraní registrátora Web4u.cz, zdroj: vlastní zpracování . . . . . . . . . . . . . . . . . . . . . . . . . .

25

3.3

Apache VS NGINX, zdroj: http://wikivs.com . . . . . . . . . . . . . .

29

3.4

Nginx: ukázka konfigurační šablony pro aplikaci Modoboa zobrazená v textovém editoru VIM, zdroj: vlastní zpracování . . . . . . . . . . . .

3.5

Zjednodušené schéma autentizačních prvků aplikační architektury, zdroj: vlastní zpracování . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.6

30 42

Ukázka administračního rozhraní PostfixAdmin, zdroj: webová stránka http://postfixadmin.sourceforge.net/screenshots/ . . . . . . . . . . . .

45

3.7

Ukázka administračního rozhraní ViMbAdmin, zdroj: vlastní zpracování 46

3.8

Ukázka administračního rozhraní Modoboa, zdroj: vlastní zpracování .

3.9

Ukázka webového rozhraní privátního cloudu s instalovanými aplikacemi, zdroj: vlastní zpracování . . . . . . . . . . . . . . . . . . . . . . . . . . 73

47 51

3.10 Ukázka nastavení e-mailu v mobilní aplikaci K-9, zdroj: vlastní zpracování 52 3.11 Ukázka webmailové aplikace Rainloop integrované do prostředí ownCloud, zdroj: vlastní zpracování . . . . . . . . . . . . . . . . . . . .

53

3.12 Ruční nastavení propojení aplikace Rainloop s cloudovou aplikací Kontakty, zdroj: vlastní zpracování . . . . . . . . . . . . . . . . . . . .

55

3.13 Ukázka nastavení okamžitého nahrávání fotek z mobilu do cloudu, zdroj: vlastní zpracování . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

59

3.14 Ukázka možností sdílení složky Photos s ostatními uživateli a s veřejností, zdroj: vlastní zpracování . . . . . . . . . . . . . . . . . . . . . . . . . .

60

3.15 Ukázka galerie a možnosti sdílení galerie, zdroj: vlastní zpracování . . .

60

3.16 Ukázka nastavení aplikace DAVdroid a kalendáře, zdroj: vlastní tvorba

62

3.17 Instalátor privátního cloudu pro Linux, zdroj: vlastní tvorba . . . . . .

63

3.18 Instalátor privátního cloudu pro Windows, zdroj: vlastní tvorba . . . .

64

3.19 Bezpečnostní varováni, které je nutné odsouhlasit, zdroj: vlastní tvorba

65

74

8. Seznam použité literatury [1] MELL, P M a T GRANCE. The NIST definition of cloud computing [online]. B.m.: National Institute of Standards; Technology (NIST). 2011. Dostupné z: doi:10.6028/nist.sp.800-145 [2] HASSAN, Qusay. Demystifying cloud computing. The Journal of Defense Software Engineering [online]. 2011, roč. 24, č., s. 16–21. Dostupné z: http://www.crosstalkonline. org/storage/issue-archives/2011/201101/201101-Hassan.pdf [3] WIKIPEDIE. Buzzword — Wikipedie: Otevřená encyklopedie [online]. 2015. Dostupné z: https://cs.wikipedia.org/w/index.php?title=Buzzword&oldid=13166535. [Online; navštíveno 19. 06. 2016] [4] THE OPEN GROUP. UNIX® Overview [online]. březen 2016. Dostupné z: https: //www2.opengroup.org/ogsys/publications. [dokument je dostupný pouze na vyžádání] [5] ZANDL, Patrick. Historie českého internetu (6.) [online]. B.m.: Lupa.cz. 2003. ISSN 1213-0702. Dostupné z: http://www.lupa.cz/clanky/historie-ceskeho-internetu-6/. [Online; navštíveno 19. 06. 2016] [6] SLACK TECHNOLOGIES, Inc. Slack: Be less busy [online]. [vid. 19. červen 2016]. Dostupné z: https://slack.com/is [7] OIKARINEN, J. a D. REED. Internet Relay Chat Protocol [online]. B.m.: Internet Engineering Task Force; RFC 1459 (Experimental); IETF. květen 1993. Request for Comments. Dostupné z: http://www.ietf.org/rfc/rfc1459.txt. Updated by RFCs 2810,

75

2811, 2812, 2813, 7194 [8] COLLINS ENGLISH DICTIONARY – COMPLETE AND UNABRIDGED. Social network - definition of Social network by The Free Dictionary [online]. [vid. 19. červen 2016]. Dostupné z: http://www.thefreedictionary.com/social%20network [9] WIKIPEDIA. RapidShare — Wikipedia, The Free Encyclopedia [online]. 2016. Dostupné

z:

https://en.wikipedia.org/w/index.php?title=RapidShare&oldid=

721873980. [Online; accessed 28-June-2016] [10] KINCAID, Jason. Dropbox Acquires The Domain Everyone Thought It Had: Dropbox.com [online]. říjen 2009 [vid. 19. červen 2016]. Dostupné z: https://techcrunch. com/2009/10/13/dropbox-acquires-the-domain-everyone-thought-it-had-dropbox-com/ [11] WEI, Wang. Apple Admits Siri Voice Data is Being shared with Third Parties Wednesday [online]. březen 2015 [vid. 19. červen 2016]. Dostupné z: http://thehackernews.com/2015/03/apple-siri-voice-data-sharing.html [12] ELZ, R. a R. BUSH. Clarifications to the DNS Specification [online]. B.m.: Internet Engineering Task Force; RFC 2181 (Proposed Standard); IETF. červenec 1997. Request for Comments. Dostupné z: http://www.ietf.org/rfc/rfc2181.txt. Updated by RFCs 4035, 2535, 4343, 4033, 4034, 5452 [13] GULBRANDSEN, A., P. VIXIE a L. ESIBOV. A DNS RR for specifying the location of services (DNS SRV) [online]. B.m.: Internet Engineering Task Force; RFC 2782 (Proposed Standard); IETF. únor 2000. Request for Comments. Dostupné z: http://www.ietf.org/rfc/rfc2782.txt. Updated by RFC 6335 [14] OPEN SOURCE INITIATIVE. The Open Source Definition [online]. březen 2007 [vid. 19. červen 2016]. Dostupné z: https://opensource.org/osd [15] WIKIPEDIE. Webový server — Wikipedie: Otevřená encyklopedie [online]. 2015. Dostupné z: https://cs.wikipedia.org/w/index.php?title=Webov%C3%BD_server& oldid=13168173. [Online; navštíveno 22. 06. 2016] [16] ELLINGWOOD, Justin. Apache vs Nginx: Practical Considerations | DigitalOcean

76

[online]. leden 2015 [vid. 22. červen 2016]. Dostupné z: https://www.digitalocean.com/ community/tutorials/apache-vs-nginx-practical-considerations [17] HEIDI, Erika. Getting Ready for PHP 7 | DigitalOcean [online]. červenec 2015 [vid. 20. červen 2016]. Dostupné z: https://www.digitalocean.com/company/blog/ getting-ready-for-php-7/ [18] OWNCLOUD.ORG. PHP 7 Is Here And ownCloud Is Ready | ownCloud.org [online].

[vid. 22. červen 2016]. Dostupné z: https://owncloud.org/blog/php-7-is-here-and-owncloud-is-ready/ [19] PEARCE, Rohan. Dead database walking: MySQL’s creator on why the future belongs to MariaDB - Computerworld [online]. [vid. 22. červen 2016]. Dostupné z:

http://www.computerworld.com.au/article/457551/dead_database_walking_

mysql_creator_why_future_belongs_mariadb/ [20] PERCONA LLC. Frequently Asked Questions about Percona Server - a MySQL Alternative [online]. [vid. 22. červen 2016]. Dostupné z: https://www.percona.com/ software/mysql-database/percona-server/faq [21] ZAWODNY, Jeremy. XtraDB: InnoDB on Steroids | Linux Magazine [online]. červen 2009 [vid. 22. červen 2016]. Dostupné z: http://www.linux-mag.com/id/7356/ [22] NGUYEN ANTOINE, ET AL. Modoboa’s documentation! — Modoboa 1.5.3 documentation [online]. [vid. 20. červen 2016]. Dostupné z: http://modoboa.readthedocs. io/en/latest/ [23] ANDERSON, Ross. Security engineering : a guide to building dependable distributed systems. Indianapolis, IN: Wiley Pub, 2008. ISBN 978-0-470-06852-6. [24] AAS, Josh. Leaving Beta, New Sponsors - Let’s Encrypt - Free SSL/TLS Certificates [online]. duben 2016 [vid. 23. červen 2016]. Dostupné z: https://letsencrypt.org/2016/ 04/12/leaving-beta-new-sponsors.html [25] FIŠER, Jakub. lego-wrapper README [online]. červen 2016 [vid. 23. červen 2016]. Dostupné z: https://github.com/cptMikky/lego-wrapper/blob/master/README.md [26] XENOLF ET AL. lego - Let’s Encrypt client and ACME library written in Go 77

README [online]. červen 2016 [vid. 23. červen 2016]. Dostupné z: https://github.com/ xenolf/lego/blob/master/README.md [27] NGUYEN, Antoine. Modoboa - Mail hosting made simple [online]. [vid. 24. červen 2016]. Dostupné z: http://modoboa.org/en/ [28] POSTFIXADMIN AUTHORS. Postfix Admin - Web based administration interface [online]. [vid. 24. červen 2016]. Dostupné z: http://postfixadmin.sourceforge.net/ [29] OPENSOLUTIONS. ViMbAdmin :: Virtual Mailbox Administration [online]. [vid. 24. červen 2016]. Dostupné z: http://www.vimbadmin.net/ [30] SOLUTIONS, Erlang. MongooseIM README [online]. [vid. 24. červen 2016]. Dostupné z: https://github.com/esl/MongooseIM/blob/master/README.md [31] GOOGLE, INC. Facebook Messenger - Obchod Google Play Store [online]. [vid. 24. červen 2016]. Dostupné z: https://play.google.com/store/apps/details?id=com. facebook.orca&hl=en [32] WIKIPEDIA. Infrastructure as Code — Wikipedia, The Free Encyclopedia [online]. 2016. Dostupné z: https://en.wikipedia.org/w/index.php?title=Infrastructure_as_ Code&oldid=724173143. [Online; accessed 27-June-2016] [33] NOTTINGHAM, M. a E. HAMMER-LAHAV. Defining Well-Known Uniform Resource Identifiers (URIs) [online]. B.m.: Internet Engineering Task Force; RFC 5785 (Proposed Standard); IETF. duben 2010. Request for Comments. Dostupné z: http://www.ietf.org/rfc/rfc5785.txt

78