pixx/WifiBP
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Vizuální úprava

Browse Source
This commit is contained in:
David Zálešák
2024-11-27 10:36:46 +01:00
parent d27ddc6e3d
commit c9015084a2
5 changed files with 24 additions and 24 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
chapters/implementace.tex
View File

@@ -74,7 +74,7 @@ Do vstupu \verb|Script to run on first boot (uci-defaults)| zadáme ash unix she
Tento script odstraní výchozí síťové nastavení systému OpenWrt. Ze souboru \verb|/etc/board.json| (popis výchozí konfigurace pro dané zařízení) zjistí původní WAN port zařízení a nad ním vytvoří nové síťové rozhraní s~vlan tagem \verb|99| pro příchozí i odchozí provoz. DHCP client na tomto novém rozhraní požádá o~přidělení IP adresy. Toto síťové rozhraní bude jediné síťové rozhraní kterému bude přidělena IP adresa. Bude sloužit pro management přístupového bodu.
Script detekuje, zda dané zařízení obsahuje switch a rozpozná jestli je spravován pomocí DSA nebo nástrojem \verb|swconfig|. DSA nebo-li Distributed Switch Architecture je subsystém Linuxového jádra pro unifikovanou správu specifických embedded switchů. Vytváří virtuální síťová rozhraní pro každý port switche, což umožňuje jejich správu standardními Linuxovými nástroji.\citep{LinuxDSA} U~DSA switche si s~nastavením VLAN tagování provozu poradí OpenWrt při vytváření síťového rozhraní pro management, zatímco switch spravovaný nástrojem \verb|swconfig| je nutné ještě nakonfigurovat tak, aby na původním WAN portu switche přijímal a odesílal rámce s~VLAN tagem 99 a tyto rámce přeposílal z~portu a na port switche připojený na ethernetové rozhraní CPU přístupového bodu také s~VLAN tagem 99.
Script detekuje, zda dané zařízení obsahuje switch a rozpozná jestli je spravován pomocí DSA nebo nástrojem \verb|swconfig|. DSA nebo-li Distributed Switch Architecture je subsystém Linuxového jádra pro unifikovanou správu specifických embedded switchů. Vytváří virtuální síťová rozhraní pro každý port switche, což umožňuje jejich správu standardními Linuxovými nástroji. \citep{LinuxDSA} U~DSA switche si s~nastavením VLAN tagování provozu poradí OpenWrt při vytváření síťového rozhraní pro management, zatímco switch spravovaný nástrojem \verb|swconfig| je nutné ještě nakonfigurovat tak, aby na původním WAN portu switche přijímal a odesílal rámce s~VLAN tagem 99 a tyto rámce přeposílal z~portu a na port switche připojený na ethernetové rozhraní CPU přístupového bodu také s~VLAN tagem 99.
Script dále provede změnu root hesla, které je definováno na začátku scriptu v~proměnné \verb|root_password| a bezpečnostní nastavení SSH démona s~přidáním SSH klíče z~proměnné \verb|ssh_key_rsa|. SSH démon není pro některé architektůry kompilován s~podporou novějších typů klíčů, proto doporučuji preferovat klíč typu RSA.
@@ -95,7 +95,7 @@ Dalším zohledněným kritériem pro výběr nástroje je jazyk zápisu konfigu
Zbylé nástroje Ansible a SaltStack využívají pro zápis konfigurace jazyk YAML a konfigurují zařízení pomocí SSH. Přesto, že fungují bez potřeby agenta většina jejich modulů vyžaduje instalaci pythonu\footnote{\url{https://docs.saltproject.io/en/latest/topics/ssh/index.html}}\footnote{\url{https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html\#managed-node-requirements}} na spravovaných zařízeních, což může být opět problematické pro přístupové body vzhledem k~jejichi omezené interní paměti (instalace Python se svými závislostmi může na systému Openwrt vyžadovat přes 9 MiB interní paměti). Z~tohoto důvodu musím vybrat nástroj \textbf{Ansible} pro jeho širokou komunitní podporu a zejména existenci projektu \verb|ansible-openwrt|\footnote{\url{https://github.com/gekmihesg/ansible-openwrt}}, jenž přepisuje příkazy některých modulů Ansiblu vyžadující python interpreter za jejich alternativy interpretované v~unixovém příkazovém procesoru a obsahuje modul uci pro konfiguraci OpenWrt.
\textbf{Ansible} je nástroj pro automatizaci konfigurace, správy a nasazení aplikací. Pro zápis požadované konfigurace lze kombinovat imperativní i deklarativní způsob. Možnosti deklarativní konfigurace jsou omezeny schopnostmi ansiblu. Je doporučeno upřednosťnovat deklarativní způsob zápisu konfigurace a k~imperativnímu přistoupit až v~momentu kdy jsme omezeni schopnostmi ansiblu.\citep{ZenofAnsible}
\textbf{Ansible} je nástroj pro automatizaci konfigurace, správy a nasazení aplikací. Pro zápis požadované konfigurace lze kombinovat imperativní i deklarativní způsob. Možnosti deklarativní konfigurace jsou omezeny schopnostmi ansiblu. Je doporučeno upřednosťnovat deklarativní způsob zápisu konfigurace a k~imperativnímu přistoupit až v~momentu kdy jsme omezeni schopnostmi ansiblu. \citep{ZenofAnsible}
\textbf{Ansible} se skládá z~těchto komponent:
\begin{itemize}
@@ -177,7 +177,7 @@ V~poslední sekci \verb|wireless_interfaces| jsou definovány dvě Wi-Fi sítě
\verb|Hostapd| je nástroj určený ke správě a vytváření Wi-Fi sítí. Kromě toho zajišťuje autorizaci zařízení a funguje jako 802.1X autentizátor, tedy zprostředkovává autentizaci mezi klientským zařízením a autetizačním serverem. V~OpenWrt je součástí balíčku \verb|wpad-mbedtls|, který jsme nainstalovali ve své plnohodnotné verzi při kompilaci.
Parametr \verb|dynamic_vlan| \verb|hostapd| definuje zda je clientské zařízení dynamicky přidělováno do vlan. Jsou definovány tři stavy. 0 - neprobíhá dynamické přiřazování vlan, 1 - VLAN není požadováno, použije se výchozí síťové rozhraní, 2 - VLAN je od RADIUS serveru požadována jinak clientské zařízení nepřipojí.
Pokud je dynamické přidělování zapnuto \verb|hostapd| Wi-Fi clienty přiřazuje do adekvátních bridgů. K~tomu potřebuje znát prefix bridge, který je definovaný v~\verb|hostapd| parametru \verb|vlan_bridge|. \verb|vlan_naming| s~hodnotou 1 říká, že do bridge bude přirazeno ethernetové rozhraní ve formátu \verb|<vlan_tagged_interface>.<VLANtag>|, v~případě hodnoty 0 je přiřazeno rozhraní s~názvem \verb|vlan<vlantag>|. V~parametru \verb|vlan_tagged_interface| je tedy uvedeno ethernetové rozhraní propojující přístupový bod a router sítě.\citep{OpenWrtDoc8021X}
Pokud je dynamické přidělování zapnuto \verb|hostapd| Wi-Fi clienty přiřazuje do adekvátních bridgů. K~tomu potřebuje znát prefix bridge, který je definovaný v~\verb|hostapd| parametru \verb|vlan_bridge|. \verb|vlan_naming| s~hodnotou 1 říká, že do bridge bude přirazeno ethernetové rozhraní ve formátu \verb|<vlan_tagged_interface>.<VLANtag>|, v~případě hodnoty 0 je přiřazeno rozhraní s~názvem \verb|vlan<vlantag>|. V~parametru \verb|vlan_tagged_interface| je tedy uvedeno ethernetové rozhraní propojující přístupový bod a router sítě. \citep{OpenWrtDoc8021X}
Druhou definovanou Wi-Fi síťí je \verb|free wifi| která nevyžaduje žádnou autentizaci a je přiřazena k~síťovému rozhraní \verb|free_wifi|.
@@ -258,7 +258,7 @@ freeRADIUS pro zajištění různých typů komunikace potřebu certifikáty. Ty
\begin{figure}
\centering
\includegraphics[width=1\textwidth]{images/radius_certifikaty.png}
\caption{Porovnání modelu ISO OSI a TCP/IP.\citep{eduroam_certifikaty}}
\caption{Porovnání modelu ISO OSI a TCP/IP. \citep{eduroam_certifikaty}}
\label{fig:radius_certifikaty}
\end{figure}
@@ -282,7 +282,7 @@ Pro získání komplexního přehledu o~přístupových bodech a síťi je potř
% ------------------------------------------------------------------------------------------------------------------
\subsection{Systémový log}
Systémové logy hrají zásadní roli při monitorování stavu zařízení. Poskytují důležité informace o~bezpečnostních incidentech, hardwarových a softwarových problémech nebo jiných událostech, které vyžadují pozornost. Aby byla tato data užitečná doporučuje se logy uchovávat alespoň jeden měsíc. Důvodem je skutečnost, že odhalení bezpečnostního incidentu může také zabrat určtitý čas.\citep{Nemeth_Evi_2008}
Systémové logy hrají zásadní roli při monitorování stavu zařízení. Poskytují důležité informace o~bezpečnostních incidentech, hardwarových a softwarových problémech nebo jiných událostech, které vyžadují pozornost. Aby byla tato data užitečná doporučuje se logy uchovávat alespoň jeden měsíc. Důvodem je skutečnost, že odhalení bezpečnostního incidentu může také zabrat určtitý čas. \citep{Nemeth_Evi_2008}
Systém OpenWrt používá nástroj \verb|logd| z~projektu ubox\footnote{\url{https://git.openwrt.org/?p=project/ubox.git}} k~řízení systémového logování. Tento nástroj sbírá logovací zprávy od všech programů běžících na systému OpenWrt a ukládá je do centrálního systémového logu. Ve výchozí konfiguraci je tento log uložen do cyklické vyrovnávací paměti umístěné v~operační paměti (RAM). Tento přístup minimalizuje zápisy do trvalé paměti zařízení, což je důležité zejména u~zařízení s~NAND pamětí, která by mohla nadměrnými zápisy degradovat.
Kvůli omezené kapacitě cyklické vyrovnávací paměti v~RAM je vhodné logy z~přístupových bodů přesměrovat na centrální logovací server přes síť.
@@ -306,7 +306,7 @@ Ze systémového logu RADIUS serveru lze tyto záznamy opět přeposlat na centr
Kromě systémového logu mohou historické záznamy o~stavu systému a hardwarových prostředcích sloužit ke zpětné analýze příčin vzniklých problémů, což usnadňuje jejich diagnostiku a řešení. Monitoring také umožňuje včas identifikovat potenciální problémy, jako je vyčerpání operační paměti nebo nedostatek výpočetní kapacity CPU, a tím zabránit výpadkům.
V~modelové implementaci jsou shromážděné informace předávány na centrální server, kde jsou uloženy a mohou být vizualizovány.
Systém OpenWrt ve svých repozitářích nabízí tyto open-source nástroje pro shromaždování informací o~systému a jejich předání dále: \verb|zabbix-agentd|, \verb|collectd|, \verb|prometheus-node-exporter-lua| \verb|snmpd| a \verb|telegraf|.\citep{RamsTech}
Systém OpenWrt ve svých repozitářích nabízí tyto open-source nástroje pro shromaždování informací o~systému a jejich předání dále: \verb|zabbix-agentd|, \verb|collectd|, \verb|prometheus-node-exporter-lua| \verb|snmpd| a \verb|telegraf|. \citep{RamsTech}
Z~těchto nástrojů jsem zvolil nástroj \verb|prometheus-node-exporter-lua| pro jeho jednoduchý princip předávání dat a existenci jeho rozšíření \verb|prometheus-node-exporter-lua-hostapd_stations|, díky kterému lze získat podrobné informace o~připojených klientech k~jednotlivých Wi-Fi sítím z~démona hostapd.
@@ -315,12 +315,12 @@ Z~těchto nástrojů jsem zvolil nástroj \verb|prometheus-node-exporter-lua| pr
% ------------------------------------------------------------------------------------------------------------------
\subsection{Síťové toky}
Z~důvodu použití překladu IP adres NAT na gatewayi je třeba zaznamenávat provozní údaje veřejných komunikačních sítí, aby byly splněny zákonné požadavky i pravidla federace eduroam.cz. Podobně jako u~logů RADIUS serveru musí být tyto údaje uchovávány alespoň 6 měsíců
Provozní údaje jsou zákonem definovány jako \textit{údaje vedoucí k~dohledání a identifikaci zdroje a adresáta, dále údaje vedoucí ke zjištění data, času, způsobu a doby trvání komunikace.}\citep{Zak_El_Kom} V~kontextu TCP/IP síťí to jsou IP adresy a použité porty zdroje a cíle, MAC adresa zdroje, druh provozu (UDP, TCP, ICMP), čas zahájení komunikace a doba trvání komunikace.
Provozní údaje jsou zákonem definovány jako \textit{údaje vedoucí k~dohledání a identifikaci zdroje a adresáta, dále údaje vedoucí ke zjištění data, času, způsobu a doby trvání komunikace.} \citep{Zak_El_Kom} V~kontextu TCP/IP síťí to jsou IP adresy a použité porty zdroje a cíle, MAC adresa zdroje, druh provozu (UDP, TCP, ICMP), čas zahájení komunikace a doba trvání komunikace.
NetFlow je protokol pro předávání informací o~síťových tocích, které vznikají agregací síťových paketů na základě údajů z~jejich hlaviček.
Na routeru předávajícím síťové pakety z~rozhraní na rozhraní je naistalován software, který provádí agregaci těchto paketů do flow dat. Pakety mohou být pro snížení náročnosti dalšího zpracování samplovány\footnote{je vybrán každý n-tý paket}, aniž by byla výrazně narušena kvalita zaznamenaných síťových toků.
Tyto flow data jsou následně poslána na server k~jejich uložení a případně dalšímu zpracování/analýze.
Tvorba dat o~síťových tocích snižuje náročnost na výpočetní výkon a šetří šířku pásma pro přenost dat, protože místo přenosu jednotlivých paketů se odesílají pouze informace o~toku. Agregací síťových toků se zvyšuje soukromí uživatelů, protože místo podrobných záznamů o~každém paketu jsou uchovávány pouze sumarizované informace o~jejich toku.\citep{Hofstede2014} Pro získání MAC adres zařízení je nutné použít netflow ve verzi V9 nebo IPFIX.
Tvorba dat o~síťových tocích snižuje náročnost na výpočetní výkon a šetří šířku pásma pro přenost dat, protože místo přenosu jednotlivých paketů se odesílají pouze informace o~toku. Agregací síťových toků se zvyšuje soukromí uživatelů, protože místo podrobných záznamů o~každém paketu jsou uchovávány pouze sumarizované informace o~jejich toku. \citep{Hofstede2014} Pro získání MAC adres zařízení je nutné použít netflow ve verzi V9 nebo IPFIX.
Většina systémů enterprise routerů nabízí možnost nastavení zaznamenávání síťových toků a jejich následné zaslání na server k~uložení/dalšímu zpracování. V~open-source systému OPNsense má tvorba\footnote{\url{https://docs.opnsense.org/manual/netflow.html}} netflow dat podporu přímo v~jádru operačního systému FreeBSD. Díky tomu je zatížení systému při tvorbě netflow minimální v~porovnání se softwarovou implementací \verb|softflowd| dostupnou například na systému OpenWrt.

2
chapters/pozadavky.tex
View File

@@ -11,4 +11,4 @@ Další Wi-Fi síť bude veřejná síť bez jakékoli autorizace přístupu na
Klíčovým požadavkem je spravovat přístupové body Wi-Fi centrálně.
V~neposlední řadě je nutné zajistit monitoring přístupových bodů a provozních údajů jednak z~důvodu zvýšení spolehlivosti sítě tak i z~důvodu legislativních požadavků vyplývajících ze zákona o~elektronických komunikacích, který říká, že právnická osoba zajišťující veřejnou komunikační síť je povinna uchovávat po dobu 6 měsíců provozní a lokalizační údaje, které jsou vytvářeny nebo zpracovávány při zajišťování jejích veřejných komunikačních sítí.\citep{Zak_El_Kom} Obdobný požadavek klade i český koordinátor sítě eduroam ve svých technických požadavcích a doporučeních pro členy federace eduroam.cz.
V~neposlední řadě je nutné zajistit monitoring přístupových bodů a provozních údajů jednak z~důvodu zvýšení spolehlivosti sítě tak i z~důvodu legislativních požadavků vyplývajících ze zákona o~elektronických komunikacích, který říká, že právnická osoba zajišťující veřejnou komunikační síť je povinna uchovávat po dobu 6 měsíců provozní a lokalizační údaje, které jsou vytvářeny nebo zpracovávány při zajišťování jejích veřejných komunikačních sítí. \citep{Zak_El_Kom} Obdobný požadavek klade i český koordinátor sítě eduroam ve svých technických požadavcích a doporučeních pro členy federace eduroam.cz.

16
chapters/site.tex
View File

@@ -32,7 +32,7 @@ Vrstvy modelu TCP/IP:
\begin{itemize}
\item \textbf{Vrstva síťového rozhraní}: Jedná se o~nejnižší vrstu modelu TCP/IP. Zajišťuje rámcování dat (rozdělení dat na menší bloky), které jsou přenášeny přes přenosové médium a řídí přístup k~tomuto médiu. Má na starosti příjímat a odesílat jednotlivé bity prostřednictvím přenosového média a zároveň detekovat a opravovat případné chyby, ke kterým mohlo dojít při přenosu dat. Vrstva síťového rozhraní může používat libovolnou přenosovou technologií (Ethernet, Wi-Fi, DSL, optická vlákna), pro kterou musí přizpůsobit přenášená data.
\item \textbf{Síťová vrstva}: Hlavním úkolem síťové vrstvy je zajistit přenost dat mezi odesílatelem a příjemcem v~různých síťích, kteří nejsou přímo spojeni. K~tomu využívá adresaci, směrování a fragmentaci (rozdělení dat na menší bloky pro přenos přes různé typy síťí). Síťová vrstva pracuje s~protokoly IP (Internet Protokol) pro adresaci a směrování a ICMP (Internet Control Message Protocol) pro diagnostiku.
\item \textbf{Transportní vrstva}: Tato vrstva také rozděluje data z~aplikační vrstvy na menší bloky (segmenty) a na straně příjemce je znovu skládá do původní podoby. Slouží k~zajištění přenosu dat mezi aplikacemi běžícími na různých zařízeních v~síťi. \textit{Podle jejich nároků a požadavků může transportní vrstva regulovat tok dat oběma směry, zajišťovat spolehlivost přenosu, měnit nespojovaný charakter přenosu (v~síťové vrstvě) na spojovaný}\citep{peterka_tcpip}, kontrolovat chyby v~přijatých datech a řídit pořadí doručených dat. Nejznámější protokoly pracující na transportní vrstvě jsou TCP pro spojovaný (vytváří iluzi nepřerušovaného spojení), spolehlivý přenost dat a UDP pro nespolehlivý přenos dat bez spojení.
\item \textbf{Transportní vrstva}: Tato vrstva také rozděluje data z~aplikační vrstvy na menší bloky (segmenty) a na straně příjemce je znovu skládá do původní podoby. Slouží k~zajištění přenosu dat mezi aplikacemi běžícími na různých zařízeních v~síťi. \textit{Podle jejich nároků a požadavků může transportní vrstva regulovat tok dat oběma směry, zajišťovat spolehlivost přenosu, měnit nespojovaný charakter přenosu (v~síťové vrstvě) na spojovaný} \citep{peterka_tcpip}, kontrolovat chyby v~přijatých datech a řídit pořadí doručených dat. Nejznámější protokoly pracující na transportní vrstvě jsou TCP pro spojovaný (vytváří iluzi nepřerušovaného spojení), spolehlivý přenost dat a UDP pro nespolehlivý přenos dat bez spojení.
\item \textbf{Aplikační vrstva}: Nejvyžší vrstva TCP/IP modelu slouží jako rozhraní mezi aplikacemi a síťovou infrastrukturou.
\end{itemize}
@@ -106,7 +106,7 @@ Aby bylo možné jednotlivé zařízení přiřazovat do různých logických s
\textbf{Access port}\footnote{přístupová port} je port sloužící k~připojení jednotlivých zařízení. Provoz je bez IEEE~802.1Q tagu, tag bývá odchozímu provozu přiřazen na přepínači.
Vlán portu muže být přidělena staticky, podle MAC adresy zařízení, podle IP adresy zařízení nebo z~autorizačního serveru.\citep{samuraj_vlan}
Vlán portu muže být přidělena staticky, podle MAC adresy zařízení, podle IP adresy zařízení nebo z~autorizačního serveru. \citep{samuraj_vlan}
\iffalse
\section{Taxonomie počítačových sítí}
@@ -169,7 +169,7 @@ Mezi dnes již málo používané aktivní síťové prvky lze zařadit:
\begin{figure}
\centering
\includegraphics[width=0.8\textwidth]{images/radius.png}
\caption{Průběh 802.1X / RADIUS autentizace.\citep{stankus_8021x}}
\caption{Průběh 802.1X / RADIUS autentizace. \citep{stankus_8021x}}
\label{fig:radius}
\end{figure}
@@ -177,11 +177,11 @@ V~architektůře autentizace pomocí IEEE 802.1X jsou tři hlavní prvky. První
Suplikant komunikuje s~autentizačním serverem pomocí EAP (Extensible Authentication Protocol) zpráv, které jsou specifikovány RFC 2284. Pro přenos EAP v~prostředí Ethernetu slouží EAPoE (EAP over Ethernet), kde EAP rámce používají EtherType \verb|0x888E|. Komunikace mezi Suplikantem a autentizátorem probíhá pouze na L2 vrstvě ISO/OSI modelu. autentizátor EAP zprávy od klienta (suplikanta) neinterpretuje, zabalí je do dalšího protokolu a přepošle je autentizačnímu serveru přes IP síť.
Autentizátor komunikuje s~autentizačním serverem pomocí jednoho z~AAA\footnote{Authentication, Authorization, Accounting - autentizace, autorizace, účtování} protokolů. Tyto protokoly se \textit{používájí pro zajištění zabezpečení síťové infrastruktury}. Mezi nejvíce používané patří RADIUS, TACACS, TACACS+, KERBEROS a DIAMETER.\citep{stankus_8021x}. Autentizační server ověřuje EAP zprávy a odpovídá autentizátoru, který na základě těchto odpovědí upravuje přístupk suplikanta k~síti a přeposílá příslušné EAP odpovědi suplikantovi. Komunikace mezi Autentizátorem a autentizačním serverem probíhá na úrovní aplikační vrstvy.
Autentizátor komunikuje s~autentizačním serverem pomocí jednoho z~AAA\footnote{Authentication, Authorization, Accounting - autentizace, autorizace, účtování} protokolů. Tyto protokoly se \textit{používájí pro zajištění zabezpečení síťové infrastruktury} \citep{lesek_8021x}. Mezi nejvíce používané patří RADIUS, TACACS, TACACS+, KERBEROS a DIAMETER. \citep{stankus_8021x}. Autentizační server ověřuje EAP zprávy a odpovídá autentizátoru, který na základě těchto odpovědí upravuje přístupk suplikanta k~síti a přeposílá příslušné EAP odpovědi suplikantovi. Komunikace mezi Autentizátorem a autentizačním serverem probíhá na úrovní aplikační vrstvy.
Proces autorizace klienta pomocí RADIUS serveru je znázorněn na obrázku \ref{fig:radius}.Po připojení klienta (suplikanta) do sítě je veškerý síťový provoz na portu blokován, dokud není dokončena autentizace Autentizátor akceptuje pouze EAPoL zprávy. Klient (suplikant) zahájí komunikaci s~autentizátorem \textbf{EAPoL-Start}, kterou zahájí autentizační proces. Autentizátor vyzve klienta (suplikant) zprávou \textbf{EAP-Request/Identity} ke sdělení identity. Klient odpoví zprávou \textbf{EAP-Response/Identity}, která obsahuje jeho identifikaci (například uživatelské jméno). Tuto zprávu autentizátor předá autentizačnímu serveru jako \textbf{RADIUS Access-Request}. V~tomto protokolu je zapouzdřena EAP zpráva.\citep{cuhel_8021x}
Proces autorizace klienta pomocí RADIUS serveru je znázorněn na obrázku \ref{fig:radius}.Po připojení klienta (suplikanta) do sítě je veškerý síťový provoz na portu blokován, dokud není dokončena autentizace Autentizátor akceptuje pouze EAPoL zprávy. Klient (suplikant) zahájí komunikaci s~autentizátorem \textbf{EAPoL-Start}, kterou zahájí autentizační proces. Autentizátor vyzve klienta (suplikant) zprávou \textbf{EAP-Request/Identity} ke sdělení identity. Klient odpoví zprávou \textbf{EAP-Response/Identity}, která obsahuje jeho identifikaci (například uživatelské jméno). Tuto zprávu autentizátor předá autentizačnímu serveru jako \textbf{RADIUS Access-Request}. V~tomto protokolu je zapouzdřena EAP zpráva. \citep{cuhel_8021x}
Autentizační server může odpovědět výzvou k~zadání dalšího ověření (hesla) pomocí \textbf{RADIUS Access-Challenge}, tento proces pokračuje dokud server neověří klientovu identitu. Po úspěšném ověření identity server odpoví zprávou \textbf{RADIUS Access-Challenge}, kterou autentizátor předá jako \textbf{EAP-Success} a povolí klientovi přístup k~síti.\citep{lesek_8021x}
Autentizační server může odpovědět výzvou k~zadání dalšího ověření (hesla) pomocí \textbf{RADIUS Access-Challenge}, tento proces pokračuje dokud server neověří klientovu identitu. Po úspěšném ověření identity server odpoví zprávou \textbf{RADIUS Access-Challenge}, kterou autentizátor předá jako \textbf{EAP-Success} a povolí klientovi přístup k~síti. \citep{lesek_8021x}
Identita uživatele je uložena v~databázi autentizačního serveru, v~externí databázi, v~systému pro správu identit, nebo na jiném autentizačním serveru.
@@ -189,7 +189,7 @@ EAP nezajišťuje šifrování ani ochranu přenášených dat. Toto mají na st
\begin{itemize}
\item \textbf{EAP-TLS}: používá pro vzájemnou autentizaci certifikáty klienta a serveru.
\item \textbf{PEAP}: Vytváří šifrovaný tunel TLS, uvnitř tunelu probíhá sekundární autentizace npř. pomocí MS-CHAPv2. Vyžaduje certifikát pouze na straně serveru.
\item \textbf{EAP-TTLS}: Funguje podobně jako PEAP, nabízí více možností sekundární autentizace (PAP, CHAP, nebo MS-CHAPv2).\citep{networkencyclopedia_eap}
\item \textbf{EAP-TTLS}: Funguje podobně jako PEAP, nabízí více možností sekundární autentizace (PAP, CHAP, nebo MS-CHAPv2). \citep{networkencyclopedia_eap}
\end{itemize}
% ------------------------------------------------------------------------------------------------------------------
@@ -200,7 +200,7 @@ eduroam je mezinárodní projekt s~cílem umožnit studentům a pracovníkům vz
\begin{figure}
\centering
\includegraphics[width=0.5\textwidth]{images/hierachicka_infrastruktura.png}
\caption{Hierachické uspořádání autentizačních serverů.\citep{eduroam_realm}}
\caption{Hierachické uspořádání autentizačních serverů. \citep{eduroam_realm}}
\label{fig:eduroam}
\end{figure}

6
chapters/sprava.tex
View File

@@ -1,14 +1,14 @@
\chapter{Automatizace konfigurace}
Konfigurační management, jakožto obor systémového inženýrství, byl vyvinut již v~50. letech 20. století ministerstvem obrany Spojených států. Sloužil jako metoda pro sledování změn v~komplexních systémech jako jsou zbraňové systémy nebo vojenská vozidla. Každá změna v~systému musela být zaznamenána včetně dokumentace, která uváděla, kdo změnu provedl a z~jakého důvodu. Cílem bylo zajistit, že stav systému bude v~kterémkoli okamžiku známý a zpětně dohledatelný. Stejná praxe byla aplikována i na počítačové systémy. Původně se dokumentovaly změny provedené v~čase. Nové softwarové nástroje umožnily přejít od dokumentace provedených změn k~definování požadovaného stavu systému.\citep{HeapAnsible}
Konfigurační management, jakožto obor systémového inženýrství, byl vyvinut již v~50. letech 20. století ministerstvem obrany Spojených států. Sloužil jako metoda pro sledování změn v~komplexních systémech jako jsou zbraňové systémy nebo vojenská vozidla. Každá změna v~systému musela být zaznamenána včetně dokumentace, která uváděla, kdo změnu provedl a z~jakého důvodu. Cílem bylo zajistit, že stav systému bude v~kterémkoli okamžiku známý a zpětně dohledatelný. Stejná praxe byla aplikována i na počítačové systémy. Původně se dokumentovaly změny provedené v~čase. Nové softwarové nástroje umožnily přejít od dokumentace provedených změn k~definování požadovaného stavu systému. \citep{HeapAnsible}
S~narůstajícím využíváním virtualizace, kontejnerizace a komplexností počítačových systémů, tedy s~narůstajícím počtem zařízení vyžadující určitou konfiguraci implementovaly tyto nástroje i automatizaci konfigurace spravované infrastruktury. Tento přístup se nazývá \textbf{Infrastructure as Code} (IaC), tedy infrastruktura jako kód. V~tomto modelu je požadovaná konfigurace infrastruktury zapsána ve strojově čitelném formátu v~souboru, podle kterého následně softwarové nástroje automaticky konfigurují jednotlivé prvky infrastruktury.
Díky zápisu požadované konfigurace se eliminuje lidská chyba při konfiguraci více zařízení a zvýší se homogennost konfigurace napříč infrastrukturou. S~použitím verzovacího systému lze umožnit verzování infrastruktury, týmovou spolupráci nad konfigurací s~důrazem na auditovatelnost konfigurace a dohledatelnost historických změn. Toto zvyšuje bezpečnost.
Automatizace konfigurace rozsáhlé infrastruktury zvýší efektivitu, ušetří čas a umožní snadnou škálovatelnost.\citep{leanDeliveryIaC}
Automatizace konfigurace rozsáhlé infrastruktury zvýší efektivitu, ušetří čas a umožní snadnou škálovatelnost. \citep{leanDeliveryIaC}
\pagebreak
Existuje několik známých open-source nástrojů pro správu infrastruktury jako kódu, každý se svými specifiky a způsob správy. Mezi nejpoužívanější opensource nástroje patří \textbf{Ansible\footnote{\url{https://www.ansible.com/}}}, \textbf{Chef\footnote{\url{https://www.chef.io/}}}, \textbf{Puppet\footnote{\url{https://www.puppet.com/}}} a \textbf{SaltStack\footnote{\url{https://saltproject.io/}}}\citep[p.~841]{Nemeth_Evi_2018}.
Existuje několik známých open-source nástrojů pro správu infrastruktury jako kódu, každý se svými specifiky a způsob správy. Mezi nejpoužívanější opensource nástroje patří \textbf{Ansible\footnote{\url{https://www.ansible.com/}}}, \textbf{Chef\footnote{\url{https://www.chef.io/}}}, \textbf{Puppet\footnote{\url{https://www.puppet.com/}}} a \textbf{SaltStack\footnote{\url{https://saltproject.io/}}} \citep[p.~841]{Nemeth_Evi_2018}.
\begin{longtable}[c]{|p{3.5cm}|p{2.5cm}|p{2.5cm}|p{2.5cm}|p{2.5cm}|}
\caption{Nástroje pro automatizaci správy infrastruktury}

8
pdfa.xmpi
View File

@@ -73,15 +73,15 @@
</rdf:Description>
<rdf:Description rdf:about="" xmlns:xmp="http://ns.adobe.com/xap/1.0/">
<xmp:CreatorTool>LaTeX with hyperref</xmp:CreatorTool>
<xmp:ModifyDate>2024-11-27T09:41:22+01:00</xmp:ModifyDate>
<xmp:CreateDate>2024-11-27T09:41:22+01:00</xmp:CreateDate>
<xmp:MetadataDate>2024-11-27T09:41:22+01:00</xmp:MetadataDate>
<xmp:ModifyDate>2024-11-27T10:23:40+01:00</xmp:ModifyDate>
<xmp:CreateDate>2024-11-27T10:23:40+01:00</xmp:CreateDate>
<xmp:MetadataDate>2024-11-27T10:23:40+01:00</xmp:MetadataDate>
</rdf:Description>
<rdf:Description rdf:about="" xmlns:xmpRights = "http://ns.adobe.com/xap/1.0/rights/">
</rdf:Description>
<rdf:Description rdf:about="" xmlns:xmpMM="http://ns.adobe.com/xap/1.0/mm/">
<xmpMM:DocumentID>uuid:E471EDA9-0143-B4EC-2929-27CBFE26697B</xmpMM:DocumentID>
<xmpMM:InstanceID>uuid:2330FEF4-F07E-36E8-1BFE-0446EDFA97BE</xmpMM:InstanceID>
<xmpMM:InstanceID>uuid:666EEE3A-6688-736A-1BA1-1F68FF4A39E4</xmpMM:InstanceID>
</rdf:Description>
</rdf:RDF>
</x:xmpmeta>