Skip to content

Automate, Protect, Optimize – IT Simplified

  • Domov
  • Windows
    • ActiveDirectory
    • DNS
  • VMware
    • Automation
    • vSphere
    • Horizon
  • Proxmox
  • Checkpoint
  • CheckMK
  • Veeam
  • Azure
  • English (US)English (US)
  • SlovenčinaSlovenčina
  • Toggle search form

Azure API Management

Posted on 12 apríla, 20258 mája, 2026 By Martin Hasin Žiadne komentáre na Azure API Management

Gateway (brána) v Azure API Management je komponent, ktorý funguje ako sprostredkovateľ medzi klientmi a backendovými službami. Jej hlavnou úlohou je prijať požiadavku od klienta, aplikovať definované pravidlá (napr. autentifikácia, limity, transformácie) a následne požiadavku smerovať do cieľovej služby.

K dispozícii sú dva hlavné typy gateway:

  • SaaS (hostovaná) Gateway – beží priamo v Azure ako súčasť služby API Management.
  • Self-hosted Gateway – kontajnerizovaná verzia gateway, ktorú si môžeš nasadiť v on-premise prostredí, v inej cloudovej platforme alebo v edge lokalitách. Umožňuje tak jednotné riadenie API aj mimo Azure.

Na čo slúži API Management Gateway?

  • Centralizované riadenie API – všetky volania API prechádzajú cez bránu, kde sa uplatňujú pravidlá definované v politike (policy).
  • Bezpečnosť – podpora OAuth 2.0, IP filtrácia, šifrované spojenie, validácia tokenov a ochrana proti zneužitiu.
  • Transformácia požiadaviek/odpovedí – možnosť prepísať hlavičky, URL cesty, formát tela požiadavky/odpovede (napr. z XML do JSON).
  • Rate limiting a throttling – ochrana backendu pred zahltením cez limity požiadaviek.
  • Monitoring a logging – integrované nástroje pre sledovanie používania API a identifikáciu problémov.
  • Verzionovanie a publikácia API – možnosť riadiť rôzne verzie API, publikovať testovacie a produkčné prostredia.

Kde sa Azure API Management hodí?

  • Organizácie s viacerými internými a externými API, ktoré potrebujú jednotný prístup a dohľad.
  • Firmy, ktoré potrebujú zabezpečiť komunikáciu medzi frontend aplikáciami a backend systémami.
  • Scenáre, kde sa kombinuje on-premise infraštruktúra s cloudovými službami.
  • Projekty s požiadavkou na API monetizáciu, monitoring alebo bezpečný prístup pre tretie strany.

Úvod do modernej správy API

V čase, keď aplikácie rastú na zložitosti a čoraz viac služieb komunikuje cez API rozhrania, stáva sa centrálne riadenie týchto rozhraní nevyhnutnosťou. Práve na tento účel slúži API Gateway – komponent, ktorý funguje ako jednotný vstupný bod pre všetky volania smerované do backendových služieb.

Popis API GW

Na obrázku vyššie vidíme typický scenár využitia API Gateway:

  • Actor (používateľ alebo klientská aplikácia) zasiela požiadavky.
  • Požiadavky prechádzajú cez API GW (API Gateway) – táto brána najskôr zabezpečí autentifikáciu používateľa alebo aplikácie.
  • Po úspešnom overení identít API Gateway následne smeruje požiadavku na príslušný backend (napr. mikroservisu, databázu, REST API a pod.).

Ako nainštalovať a nakonfigurovať Azure API Gateway (API Management)

Krok 1 – Prihlásenie do Azure portálu

Ako prvý krok sa vyžaduje prihlásenie do portálu https://portal.azure.com.

Krok 2 – Vytvorenie novej služby API Management

  1. Klikni na „Create a resource“ (vľavo hore).
  2. Vyhľadajte API Management.
  3. Kliknite na API Management a následne „Create“.

Krok 3 – Vyplnenie parametrov služby

Vo formulári sa vyplnia nasledovné polia:

  • Subscription – zvolí sa aktívne predplatné.
  • Resource group – vyberie sa existujúca skupina zdrojov alebo sa vytvorí nová (napr. api-gw-group).
  • Resource Name –zadá sa názov služby (napr. moja-api-gateway).
  • Region – vyberie sa preferovaný geografický región (napr. West Europe).
  • Organization name – uvedie sa názov organizácie alebo tímu.
  • Administrator email – zadá sa emailová adresa správcu, na ktorú budú zasielané notifikácie.

Po vyplnení údajov sa pokračuje kliknutím na Review + create a následne na Create, čím sa spustí nasadenie služby.

Sekcia Networking v Azure API Management – možnosti a nastavenie konektivity

Služba Azure API Management (APIM) ponúka viacero spôsobov, ako môže byť API Gateway sprístupnená klientskym aplikáciám – buď verejne prostredníctvom internetu, alebo súkromne len v rámci zabezpečeného sieťového prostredia. Výber režimu pripojenia má zásadný vplyv na bezpečnosť, architektúru a spôsob integrácie riešenia.

  1. External (verejná konektivita)
    • API Gateway je dostupná cez verejnú IP adresu – prístupná z internetu bez potreby špeciálneho sieťového pripojenia
    • Použitie:
      • Webové/mobilné aplikácie bežiace mimo Azure
      • Externí partneri alebo zákazníci
      • Rýchle testovanie alebo vývoj
  2. Internal (vnútorná konektivita – VNet Integration)
    • Prístup len z Azure Virtual Network
      Gateway beží v privátnom režime – dostupná len pre zdroje v tej istej VNet alebo cez privátne pripojenie (napr. VPN, ExpressRoute).
    • Použitie:
      • Systémy s citlivými dátami
      • Firemné API rozhrania neprístupné z verejného internetu
      • Hybridné scenáre (on-premise + cloud)
  3. Hybridný model – kombinácia Public + VNet
    • Niektoré časti API môžu byť verejné (napr. open API pre tretie strany), iné len pre interné systémy.
      Možné v režime Premium Tier, kde môžeš konfigurovať viaceré regionálne inštancie a zmiešanú konektivitu.
    • Použitie:
      • Veľké organizácie s viacerými požiadavkami na prístup
      • API rozhrania pre verejnosť aj interné tímy

Krok 1: Vytvorenie Azure Virtual Network

Ak ešte nie je vytvorená Virtual Network, je potrebné ju zriadiť nasledovne:

  1. V prostredí Azure Portal sa vyberie možnosť Create a resource.
  2. Do vyhľadávacieho poľa sa zadá výraz Virtual Network a vyberie sa príslušná služba.
  3. Sieť sa pomenuje (napr. apim-vnet).
  4. V časti IP Addressing sa pridá adresný rozsah, napríklad 10.1.0.0/16.
  5. V sekcii Subnets sa vytvorí subnet s názvom apim-subnet, napríklad 10.1.0.0/24.

Krok 2: Zriadenie verejnej IP adresy

Následne je potrebné vytvoriť verejnú IP adresu, ktorá bude slúžiť ako vstupný bod pre prichádzajúce požiadavky:

  1. V Azure Portal sa opäť vyberie možnosť Create a resource.
  2. Vyhľadá sa služba Public IP address.
  3. IP adresa sa pomenuje (napr. apim-public-ip).
  4. V časti SKU sa zvolí možnosť Standard (vyžadovaná pri integrácii s VNet).
  5. V sekcii priradenia sa vyberie Static – IP adresa sa po vytvorení nebude meniť.

Táto verejná IP adresa bude neskôr priradená k službe API Management a bude slúžiť ako verejný prístupový bod pre klientov.

Krok 3: Priradenie VNet a verejnej IP k APIM

Po vytvorení siete a IP adresy sa konfigurácia dokončí nasledovne:

  1. V Azure Portáli sa otvorí existujúca služba API Management (APIM).
  2. V ľavom menu sa prejde do časti Network → Virtual Network → Configure.
  3. Zvolí sa režim External.
  4. Vyberie sa vytvorená sieť apim-vnet a subnet apim-subnet.
  5. V sekcii Public IP address sa vyberie adresa apim-public-ip.
  6. Zmeny sa potvrdia kliknutím na Apply.
  7. Poznámka: Zmena môže trvať 15–45 minút.

Ako vytvoriť API v Azure API Management

Po nasadení API Gateway do Azure API Management (APIM) je ďalším krokom vytvorenie samotného API rozhrania, cez ktoré budú chodiť požiadavky od klientov a aplikácií. APIM umožňuje jednoducho vytvoriť nové API, alebo importovať už existujúce špecifikácie (napr. OpenAPI / Swagger / WSDL).


Možnosti ako vytvoriť API

V prostredí Azure API Management je možné API rozhranie vytvoriť niekoľkými spôsobmi:

  • Import existujúcej OpenAPI špecifikácie (Swagger)
  • Import SOAP služby na základe WSDL definície
  • Prepojenie s existujúcou službou v Azure App Service alebo Azure Functions
  • Vytvorenie prázdneho API (Blank API) a manuálne pridanie operácií

Krok 1: Otvor Azure API Management a prejdite do časti „APIs“

  1. V Azure portáli sa otvorí vytvorená služba API Management.
  2. V ľavom paneli navigácie sa klikne na položku „APIs“.
  3. Pre pridanie nového API sa zvolí možnosť „+ Add API“ alebo „Create from scratch“, v závislosti od preferovaného spôsobu vytvorenia rozhrania.

Na obrázku vyššie je zobrazené rozhranie pre návrh a úpravu API v službe Azure API Management. Ide o priestor, v ktorom sa konfiguruje správanie API brány – vrátane spracovania vstupných požiadaviek, úprav odpovedí, definovania jednotlivých operácií a aplikovania politiky (policies). Pomocou tohto rozhrania je možné podrobne riadiť spôsob, akým sa spracúvajú požiadavky od klientov ešte pred ich odoslaním na backend, ako aj upraviť odpovede pred ich vrátením klientovi.

Rozhranie je rozdelené do štyroch hlavných sekcií (zľava doprava):

  1. Navigačný panel (ľavá strana)
    • Search APIs / operations – umožňuje vyhľadávať v zozname tvojich API alebo ich operácií.
    • Add API – tlačidlo na pridanie nového API do služby.
    • All APIs – zoznam všetkých API, ktoré máš vytvorené.
    • V príklade je zobrazené Echo API – vzorové/testovacie API dostupné po inštalácii.
  2. Frontend definícia operácie
    • Zobrazuje detaily aktuálnej operácie, v tomto prípade:
      • GET /resource
      • Operácia má query parametre: param1 (string) a param2 (number)
    • Odpoveď z operácie je indikovaná ako 200 OK (úspešná odpoveď).
    • Tu sa definuje:
      • Metódu (GET, POST, atď.)
      • Cestu (/resource)
      • Parametre
      • Typ odpovede (napr. JSON, XML)
  3. Inbound processing (vstupné spracovanie)
    • Táto sekcia definuje, čo sa má stať so žiadosťou od klienta, predtým než sa pošle na backend.
    • Tu sa definuje politika (policies) ako napríklad:
      • Overenie JWT tokenu (validate-jwt)
      • Limitovanie prístupov (rate-limit)
      • Úprava hlavičiek alebo URL (rewrite-uri, set-header)
    • Na obrázku vidíme, že je tu pridaná základná politika označená ako base.
  4. Backend sekcia
    • Zobrazuje HTTP(S) endpoint, kam sa má požiadavka smerovať.
    • V tomto prípade: http://echoapi.cloudapp.net/api
    • To znamená, že požiadavky, ktoré prejdú cez gateway, sa posielajú na tento backend.
    • V tejto časti môžu byť pridané politiky, napríklad na úpravu URL adresy alebo na zabezpečenie požiadaviek.
  5. Outbound processing (výstupné spracovanie)
    • Táto sekcia určuje, ako sa má upraviť odpoveď z backendu predtým, ako sa pošle klientovi.
    • Príklady použitia:
      • Odstránenie alebo pridanie hlavičiek
      • Transformácia XML na JSON
      • Logovanie odpovedí
    • Na obrázku je použitá základná politika base.

Vytvorenie nového HTTP API

Na obrázku vyššie vidíme formulár, ktorý sa zobrazí po kliknutí na „+ Add API“ a následne výbere možnosti HTTP API. Tento formulár slúži na základné nastavenie nového API rozhrania, ktoré bude sprístupnené cez API Gateway.

Nižšie sú uvedené vysvetlenia jednotlivých polí:

  1. Display name:
    • Viditeľný názov API, ktorý sa zobrazí v rozhraní APIM.
    • Môže byť akýkoľvek – v tomto prípade:
      • Returns the requester’s IP Address
  2. Name:
    • Interný identifikátor API – používa sa v URL a v systémových záznamoch.
    • Automaticky sa generuje z názvu, ale môžete ho upraviť (napr. bez medzier, malé písmená).
    • V príklade:
      • returns-the-requester-s-ip-address
  3. Description:
    • Krátky popis API – nepovinné, ale odporúčané pre prehľadnosť.
    • Tu slúži na vysvetlenie účelu:
      • Returns the requester’s IP Address
  4. Web service URL:
    • Najdôležitejšie pole – sem zadávate reálnu URL adresu backendovej služby, kam má byť požiadavka smerovaná.
    • V tomto prípade ide o verejne dostupné testovacie API:
      • https://httpbin.org
  5. URL scheme:
    • Vyberáš, či bude API fungovať cez HTTP, HTTPS, alebo oboje.
    • Odporúčané je používať len HTTPS pre zabezpečenú komunikáciu.
  6. API URL suffix:
    • Sufix, ktorý sa pripojí k doméne APIM – tvorí finálnu adresu API.
    • Napr. ak zvolíš ip, výsledný endpoint bude:
      • https://mhi...api.azure-api.net/ip
  7. Base URL (automaticky vygenerované):
    • Základná adresa tvojej API Management brány – nedá sa upravovať.
    • V tomto prípade:
      • https://mhi...azure-api.net
  8. Tags:
    • Nepovinné pole – slúži na kategorizáciu a filtrovanie API.
    • Užitočné pri veľkom počte API (napr. internal, external, booking, atď.)
  9. Products:
    • API musí byť pridelené aspoň jednému produktu, inak nebude publikované.
    • Produkt je „balík“ API, ktorý sa poskytuje používateľom (napr. Free Tier, Premium APIs).
Pridanie operácie: GET /ip – návrh požiadavky a odpovede

Na obrázku vyššie vidíme obrazovku, kde práve prebieha konfigurácia konkrétnej API operácie typu GET. Táto operácia sa volá Returns the requester's IP Address a bude slúžiť na získanie IP adresy volajúceho klienta. Táto požiadavka bude presmerovaná na testovaciu službu https://httpbin.org/ip.

  1. Display name:
    • Interný identifikátor operácie – bez medzier a diakritiky.
    • Používa sa v interných API exportoch a systémových volaniach.
    • V príklade:
      • returns-the-requester-s-ip-address
  2. URL:
    • Tu je možné definovať:
      • Metódu: GET
      • Cestu: /ip
    • Kombináciou API suffixu a tejto cesty vznikne finálny endpoint, napríklad:
      • https://.azure-api.net/ip
  3. Sekcia Responses:
    • V tejto časti sa definujú očakávané odpovede od backendu, ktoré sú spracovávané bránou (gateway).
    • V tomto prípade je zadefinovaná odpoveď:
      • Status code: 200 OK
      • Popis (vpravo) – zatiaľ prázdny, ale môže obsahovať JSON príklad odpovede, schému alebo poznámky.

Ako otestovať API cez cURL príkaz

Po vytvorení a nasadení API v službe Azure API Management je vhodné vykonať testovanie mimo portálu – napríklad prostredníctvom príkazového riadku pomocou nástroja cURL.

V predvolenom nastavení Azure API Management vyžaduje, aby každá požiadavka bola autorizovaná pomocou tzv. subscription key. Tento kľúč sa pridáva buď vo forme HTTP hlavičky (Ocp-Apim-Subscription-Key), alebo ako parameter priamo v URL (?subscription-key=...).

Ak je však anonymný prístup povolený, API je možné testovať aj bez použitia subscription key. Tento režim sa využíva najmä pre verejne dostupné API rozhrania alebo na účely testovania.

Zapnutie overovania pomocou subscription key

Azure API Management umožňuje viacero spôsobov overovania požiadaviek, ktoré smerujú na publikované API. Výber konkrétnej metódy závisí od požiadaviek na bezpečnosť, typ klienta, ako aj účel samotného API (verejné vs. interné). Overovanie zabezpečuje, že API môže volať len oprávnený používateľ alebo aplikácia.

Subscription key (predvolená metóda) – Každé API je možné zabezpečiť pomocou tzv. subscription key, ktorý sa vkladá do požiadavky:

  1. buď do HTTP hlavičky:
    • Ocp-Apim-Subscription-Key:
  2. alebo ako parameter v URL:
    • ?subscription-key=

Subscription key v službe Azure API Management je bezpečnostný token, ktorý slúži na identifikáciu a autorizáciu klientov pristupujúcich k publikovaným API rozhraniam. Ide o jednoduchý, ale efektívny spôsob zabezpečenia API pred neautorizovaným prístupom. Subscription key má podobu náhodne generovaného reťazca, zvyčajne dlhého 32 až 40 znakov, napríklad 1a2b3c4d5e6f7g8h9i0jklmnopqrstuv, a neobsahuje žiadne špeciálne znaky.

Každý kľúč je viazaný na konkrétnu subscription (predplatné), ktoré patrí k vybranému produktu v rámci služby APIM. Pre každé subscription sa automaticky generujú dva kľúče – primárny a sekundárny, pričom ich platnosť je rovnaká a môžu byť kedykoľvek obnovené (regenerované). Okrem autorizácie požiadaviek umožňuje subscription key aj sledovanie spotreby, aplikovanie kvót, obmedzení rýchlosti (rate limiting) a evidenciu prístupu podľa používateľov alebo aplikácií. V prostredí s viacerými klientmi alebo partnermi poskytuje efektívny spôsob správy a zabezpečenia prístupu k rozhraní bez nutnosti zložitej autentifikačnej logiky.

Martin Hasin
CEO at mhite S.R.O. | martin.hasin@gmail.com | Website |  + postsBio

Odborník na kybernetickú bezpečnosť, správu Azure Cloud a VMware onprem. Využíva technológie, ako Checkmk a MRTG, na monitorovanie siete a zvyšovanie efektívnosti a bezpečnosti IT infraštruktúry. Kontakt: hasin(at)mhite.sk

  • Martin Hasin
    VRA Ubuntu 26.04 Server Template — Kompletná šablóna pre vRealize Automation
  • Martin Hasin
    Cisco Nexus VPC klaster pre PROXMOX – Kompletný návodCisco Nexus VPC Cluster for PROXMOX – Complete Guide
  • Martin Hasin
    Windows 11 v Azure s Entra ID – Kompletný návodWindows 11 in Azure with Entra ID – Complete Guide
  • Martin Hasin
    Overenie prístupu k Azure SQL – Kompletný návodAzure SQL Access Verification – Complete Guide
  • Martin Hasin
    Veeam Backup Replication v13 Linux Appliance – Kompletný návodVeeam Backup Replication v13 Linux Appliance – Complete Guide
  • Martin Hasin
    Check Point VSX DHCP Relay – Konfigurácia
  • Martin Hasin
    K3s na Raspberry Pi – Od nápadu po funkčný Kubernetes klaster
  • Martin Hasin
    Zálohovanie MinIO S3 s Veeam – Kompletný návod
  • Martin Hasin
    Zálohovanie klientskych staníc – Legislatíva a praktické dôvody
  • Martin Hasin
    MSSQL transakčné logy – Správa diskového priestoru
  • Martin Hasin
    Cisco UCS C220 M7 monitoring a logovanie Part 7
  • Martin Hasin
    Cisco UCS C220 M7 vSphere Lifecycle Manager Part 6
  • Martin Hasin
    Cisco UCS C220 M7 VMware sieť a vMotion Part 5
  • Martin Hasin
    Cisco UCS C220 M7 ESXi a vCenter Part 4
  • Martin Hasin
    Cisco UCS C220 M7 sieťová architektúra Part 3
  • Martin Hasin
    HTTPS Inspection v korporátnom prostredí
  • Martin Hasin
    Cisco UCS C220 M7 VMware klaster Part 2
  • Martin Hasin
    Cisco UCS C220 M7 VMware klaster
  • Martin Hasin
    Zálohovanie Microsoft 365 – Prečo cloud nie je zálohovaný
  • Martin Hasin
    Ubuntu Hardened Repository Veeam
  • Martin Hasin
    CIS Benchmark: Štandard pre posilnenie kybernetickej bezpečnosti 2CIS Benchmark: Cybersecurity Hardening Standard Part 2
  • Martin Hasin
    CIS Benchmark
  • Martin Hasin
    Azure Backup SQL s Veeam
  • Martin Hasin
    SNIA Data Protection Best Practices
  • Martin Hasin
    Veeam monitoring CheckMK
  • Martin Hasin
    Azure Automation
  • Martin Hasin
    Veeam Hardened Repository
  • Martin Hasin
    Ako a prečo zálohovať Active DirectoryHow and Why to Backup Active Directory
  • Martin Hasin
    Zálohovanie Entra ID pomocou Veeam
  • Martin Hasin
    Veeam Backup pre Proxmox VM
  • Martin Hasin
    Zabezpečenie Windows Servera s Veeam
  • Martin Hasin
    Grafana Dashboard pre Veeam
  • Martin Hasin
    Veeam Backup NFS Fileshare
  • Martin Hasin
    VRA Ubuntu Template
  • Martin Hasin
    Azure SQL Server zabezpečenie
  • Martin Hasin
    Azure Storage Account zabezpečenie
  • Martin Hasin
    Microsoft Authenticator
  • Martin Hasin
    Virtual WAN VPN Server
  • Martin Hasin
    VRA Windows vytvorenie šablóny
  • Martin Hasin
    Azure REST API Reset Analysis Services
  • Martin Hasin
    Azure Purview Data Security
  • Martin Hasin
    Azure Office 365 Data Security
  • Martin Hasin
    Azure Elasticsearch Log Server
  • Martin Hasin
    Azure SQL Server Export BACPAC
  • Martin Hasin
    Azure Communication Services Email
  • Martin Hasin
    Backup Azure Fileshare Duplicati
  • Martin Hasin
    Azure Key Vault Backup
  • Martin Hasin
    Azure Fileshare pripojenie Ubuntu
  • Martin Hasin
    DLP ochrana dát v Azure
  • Martin Hasin
    Azure Blob Storage ochrana pred ransomware
  • Martin Hasin
    Azure Cloud zálohovanie
  • Martin Hasin
    Windows Server RDP Brute Force ochrana
  • Martin Hasin
    Azure Private Link VPN
  • Martin Hasin
    Azure Point-to-Site VPN
  • Martin Hasin
    VMware VCSA výmena certifikátu
  • Martin Hasin
    CheckMK Nextcloud plugin
  • Martin Hasin
    Inštalácia CheckMK
  • Martin Hasin
    Check Point zväčšenie partície log
  • Martin Hasin
    VMware ESXi vlastné inštalačné médium
  • Martin Hasin
    VRA Windows 11 šablóna
  • Martin Hasin
    Active Directory NTP server
  • Martin Hasin
    AD AllowNT4Crypto zabezpečenie
  • Martin Hasin
    CentOS Stream 9 šablóna pre VRA
  • Martin Hasin
    Windows DNS a Linux DNS replikácia
  • Martin Hasin
    Inštalácia Active Directory 2022 časť 2
  • Martin Hasin
    Inštalácia Active Directory 2022
  • Martin Hasin
    vCenter VMSA-2021-0028 oprava
  • Martin Hasin
    VMware Coredump Collector
  • Martin Hasin
    Windows VMware disk štatistiky
  • Martin Hasin
    Ubuntu šablóna pre VRA
  • Martin Hasin
    VMware vCenter API príkazy
  • Martin Hasin
    Pridanie ESXi do vCenter
  • Martin Hasin
    Vytvorenie datastore v ESXi
  • Martin Hasin
    Inštalácia VMware ESXi 7
  • Martin Hasin
    Inštalácia VMware vCenter 7
Azure Tags:azure, Azure API Gateway, Azure API Management

Navigácia v článku

Previous Post: VMware vCenter token Broadcom – Nová autentifikácia
Next Post: Zálohovanie Microsoft 365 – Prečo cloud nie je zálohovaný

Pridaj komentár Zrušiť odpoveď

Vaša e-mailová adresa nebude zverejnená. Vyžadované polia sú označené *

Search

Archives

  • máj 2026
  • január 2026
  • november 2025
  • október 2025
  • september 2025
  • august 2025
  • júl 2025
  • máj 2025
  • apríl 2025
  • marec 2025
  • február 2025
  • január 2025
  • december 2024
  • november 2024
  • júl 2024
  • jún 2024
  • máj 2024
  • marec 2024
  • február 2024
  • január 2024
  • december 2023
  • jún 2023
  • apríl 2023
  • november 2022
  • október 2022
  • august 2022
  • júl 2022
  • marec 2022
  • február 2022
  • január 2022
  • december 2021
  • november 2021
  • október 2021

Categories

  • ActiveDirectory
  • Automation
  • Azure
  • CheckMK
  • Checkpoint
  • DNS
  • Linux
  • Proxmox
  • Uncategorized
  • Veeam
  • VMware
  • vSphere
  • Windows

Archives

  • máj 2026
  • január 2026
  • november 2025
  • október 2025
  • september 2025
  • august 2025
  • júl 2025
  • máj 2025
  • apríl 2025
  • marec 2025
  • február 2025
  • január 2025
  • december 2024
  • november 2024
  • júl 2024
  • jún 2024
  • máj 2024
  • marec 2024
  • február 2024
  • január 2024
  • december 2023
  • jún 2023
  • apríl 2023
  • november 2022
  • október 2022
  • august 2022
  • júl 2022
  • marec 2022
  • február 2022
  • január 2022
  • december 2021
  • november 2021
  • október 2021

Copyright © 2021 Martin Hasin.

Powered by PressBook WordPress theme

Spravujte súhlas so súbormi cookie
Na poskytovanie tých najlepších skúseností používame technológie, ako sú súbory cookie na ukladanie a/alebo prístup k informáciám o zariadení. Súhlas s týmito technológiami nám umožní spracovávať údaje, ako je správanie pri prehliadaní alebo jedinečné ID na tejto stránke. Nesúhlas alebo odvolanie súhlasu môže nepriaznivo ovplyvniť určité vlastnosti a funkcie.
Funkčné Vždy aktívny
Technické uloženie alebo prístup sú nevyhnutne potrebné na legitímny účel umožnenia použitia konkrétnej služby, ktorú si účastník alebo používateľ výslovne vyžiadal, alebo na jediný účel vykonania prenosu komunikácie cez elektronickú komunikačnú sieť.
Predvoľby
Technické uloženie alebo prístup je potrebný na legitímny účel ukladania preferencií, ktoré si účastník alebo používateľ nepožaduje.
Štatistiky
Technické úložisko alebo prístup, ktorý sa používa výlučne na štatistické účely. Technické úložisko alebo prístup, ktorý sa používa výlučne na anonymné štatistické účely. Bez predvolania, dobrovoľného plnenia zo strany vášho poskytovateľa internetových služieb alebo dodatočných záznamov od tretej strany, informácie uložené alebo získané len na tento účel sa zvyčajne nedajú použiť na vašu identifikáciu.
Marketing
Technické úložisko alebo prístup sú potrebné na vytvorenie používateľských profilov na odosielanie reklamy alebo sledovanie používateľa na webovej stránke alebo na viacerých webových stránkach na podobné marketingové účely.
  • Spravovať možnosti
  • Správa služieb
  • Spravovať {vendor_count} dodávateľov
  • Prečítajte si viac o týchto účeloch
Zobraziť predvoľby
  • {title}
  • {title}
  • {title}