Mi a célja és hogyan működik a proaktív adatgyűjtés a modern adatfolyamaikban?

A modern adatkezelési rendszerekben egyre fontosabb szerepet kapnak az automatizált adatgyűjtési és -feldolgozási folyamatok. A felhasználók és a számítógépek adatokat küldenek valahová tárolásra és elemzésre, és az adatmérnökök feladata, hogy biztosítsák az adatok célba érését. Az adatcsövek, vagy adatfolyamok, gyakran passzív módon fogadják az adatokat, de bizonyos esetekben aktívan is lekérhetik azokat – és ez a proaktív adatgyűjtés, mely a modern adatkezelési rendszerek szerves részévé vált.

A Logstash, mint adatfeldolgozó eszköz, képes fogadni az adatokat, és JSON formátumba alakítani azokat, mielőtt azok a végső célba érkeznének, például egy SIEM rendszerbe (Security Information and Event Management) vagy adatbázisba. Az adatcső ezen szakasza lehetővé teszi, hogy a Logstash ne csak passzívan fogadja az eseményeket, hanem aktívan lekérje őket egy API-n keresztül HTTPS-en. Például egy adott IP-cím, domain név vagy fájl hash értéket küldhetünk egy online szolgáltatásnak, hogy megbecsüljük a hírnevét vagy phishing jelzéseket kapjunk.

A másik fontos adatkezelési mechanizmus, amely szerepet játszik a proaktív adatgyűjtésben, az adatközpontok közötti ideiglenes adatcentralizálás. Egy szervezet biztonsági adatai nemcsak az elemzők számára fontosak, hanem megfelelőségi csapatok, szezonális auditálók vagy a belső fenyegetésekkel foglalkozó csapatok számára is. A Kafka például egy olyan platform, amely összeköti az adatküldő és adatfogadó fél között lévő különböző szolgáltatásokat. A Kafka segítségével az adatokat nem közvetlenül küldjük tovább, hanem a felhasználók és a szolgáltatások csatlakoznak a platformhoz, hogy közzétegyék (publish) vagy fogadják (subscribe) az adatokat. A Kafka által biztosított adatcsövek segítenek az adatfolyamok központi feldolgozásában és az adatmegosztás egyszerűbbé tételében.

Ezen kívül az adatcsövek folyamatosan érkező adatok kezelésében egyre fontosabb szerepet kapnak a gyors elérésű adattárolók, mint például a cache rendszerek. A cache egy gyorsítótárat tartalmaz, amely adatokat tárol a rendszer memóriájában, lehetővé téve az adatok szinte azonnali elérését. A cache segíthet abban, hogy az események gyorsan összehasonlíthatók legyenek a tárolt értékekkel, mielőtt azok eljutnának a végső feldolgozásra. Például egy fenyegetettségi adatbázis IP-címeket vagy webdomaineket tartalmazhat, és a cache lehetővé teszi ezek gyors keresését az adatok elemzése előtt.

A modern adatkezelés során elengedhetetlen, hogy a különböző rendszerek és eszközök képesek legyenek egymással kommunikálni és adatokat cserélni. Ezt a feladatot az adat-serializálási formátumok segítik elő. A serializálás során az adatokat egy olyan formátumba alakítjuk, amely lehetővé teszi azok küldését hálózaton, tárolását adatbázisokban vagy más nyelveken történő feldolgozását. A leggyakoribb formátumok közé tartozik a JSON és a YAML, amelyeket a könyv későbbi fejezeteiben részletesen is bemutatunk.

A JSON, vagy JavaScript Object Notation, a legelterjedtebb adatformátum a különböző rendszerek közötti adatcsere során. A JSON kulcs-érték párok sorozataként formázza az adatokat, és könnyen olvasható mind az emberek, mind a gépek számára. A YAML, amely egy rekurzív akronímja a „YAML Ain’t Markup Language” kifejezésnek, egy másik adatformátum, amelyet inkább konfigurációs fájlok létrehozására és szerkesztésére használnak. A YAML-t különböző konfigurációs fájlokban használjuk, mivel tisztán és olvashatóan ábrázolja az adatokat anélkül, hogy túlságosan komplex szintaxist igényelne.

Hogyan használjuk a Filebeat-ot hálózati bemenetekhez és külső rendszerekhez való kapcsolódáshoz?

A Filebeat számos hálózati bemenetet kínál, amelyek lehetővé teszik a távoli rendszerek adatainak fogadását TCP, UDP és Unix socketeken keresztül. Ezen kívül HTTP alkalmazásprogramozási interfész (API) végpontként is működhet, amely kéréseket fogad, és HTTP kéréseket küld előre meghatározott időközönként. Az alábbiakban bemutatjuk, hogyan konfigurálhatjuk a Filebeat-ot a syslog üzenetek fogadására a hálózaton keresztül.

A syslog üzenetek fogadásához, ha sima szöveges (nem titkosított) hallgatót szeretnénk használni, adjunk hozzá egy új bemeneti típust a filebeat.yml fájlhoz, a filestream szekció alatt:

yaml
Copy code
- type: syslog

  id: syslog-tcp-5514
  enabled: true
  format: auto
  tags: [ "forwarded" ]
  protocol.tcp:
    host: "localhost:5514"
  exclude_lines: ['.*UFW.*']

A syslog bemeneti típus használatával az auto formátum automatikusan felismeri mind az RFC 3164, mind az RFC 5424 típusú syslog üzeneteket. A forwarded címke hozzáadásával jelezhetjük, hogy az üzenetek más helyről származnak. A Filebeat a localhost 5514-es portján figyel TCP kapcsolatokra, mivel az alábbi 1024-es portok (beleértve a standard syslog portot, a 514/TCP-t) emelt szintű jogosultságokat igényelnek. A tűzfal naplókat célszerű külön nyomon követni a nagy mennyiségű forgalom miatt, így az UFW kifejezéssel rendelkező sorokat ki kell zárni a feldolgozásból.

Ha már működtetjük a Rsyslog-ot, egyszerűen hozzáadhatjuk a következő sort az /etc/rsyslog.d/send-to-filebeat.conf fájlhoz, majd újraindíthatjuk a Rsyslog szolgáltatást:

bash
Copy code
*.* @@localhost:5514

A dupla at jel (@@) a TCP-t jelenti. Ha UDP-t szeretnénk használni, akkor egyetlen at jelet kell alkalmazni. Ezután indítsuk újra a Filebeat-ot, és figyeljük meg, hogy a forwarded címke megjelenik az adatfolyamban:

json
Copy code
"message" => "pam_unix(sudo:session): session closed for user root",

"tags" => [
    "tags-for-everybody",
    "you-get-a-tag",
    "and-you-get-a-tag",
    "forwarded",
    "beats_input_codec_plain_applied"
],
"log" => {
    "source" => {
        "address" => "127.0.0.1:46474"
    }
},
"@version" => "1",
"process" => {
    "program" => "sudo"
},
"syslog" => {
    "facility_label" => "security/authorization",
    "facility" => 10,
    "priority" => 86,
    "severity_label" => "Informational"
}

Most a Filebeat már képes fogadni és továbbítani az adatokat egy távoli rendszerből. Azt is észrevehetjük, hogy a sudo program neve most a process.program alatt van, míg a filestream bemenet a syslog.appname alatt helyezkedik el. Erre érdemes figyelni, mivel lehet, hogy később a Logstash vagy egy Filebeat feldolgozó segítségével a nevet a kívánt process.name mezőbe szeretnénk másolni. Fontos megjegyezni, hogy a Filebeat-ban található modulok, amelyek a folyamatinformációkat kinyerik, helyesen helyezik el a nevet a process.name mezőben, de az filebeat.yml-ben definiált bemenetek nem mindig igazodnak teljes mértékben az ECS struktúrához.

A Filebeat képes elérni a külső rendszereket is adatlekérés céljából. Ez hasznos lehet olyan rendszerek esetén, amelyek nem képesek saját maguk adatokat küldeni, illetve olyan rendszerek számára, amelyeknek szükségük van egy közvetítőre a hálózati határok átlépéséhez. Például, az eseménynaplókat tároló rendszerek, mint a Kafka, nem küldenek adatokat közvetlenül más rendszereknek, hanem a termelők adatokat küldenek a Kafka-ba, míg a fogyasztók kinyerik az adatokat belőle. A Filebeat mindkét szerepet el tudja látni.

A Kafka kapcsolódáshoz a következő beállításokat kell hozzáadnunk a filebeat.yml fájlhoz:

yaml
Copy code
- type: kafka

  enabled: true
  hosts:
    - kafka01:9093
    - kafka02:9093
  topics: [ "filebeat" ]
  group_id: "filebeat"
  tags: [ "from-kafka" ]
  parsers:
    - ndjson:
        message_key: "message"
        target: "processed"
        overwrite_keys: true
        add_error_key: true

A hosts mezőben két Kafka broker szerepel, amelyek a szerver csomópontokat jelölik, amelyek feldolgozzák az üzeneteket. Érdekesség, hogy ezek nem feltétlenül a célpontok, ahová a Filebeat küldeni fogja az adatokat, hanem gyakran úgynevezett bootstrap szerverek, amelyek metaadatokat adnak vissza a Kafka klaszter belső csomópontjairól. A Filebeat ezeket az adatokat olvassa ki, és a tényleges brokerhez továbbítja az adatokat.

Ezután meghatározzuk a topicot, amely az az eseményfolyam, amelyhez csatlakozni szeretnénk, és amelyből adatokat olvasunk. A topicokat stringek tömbjeként adjuk meg. A fenti példában egyetlen topicot adunk meg, amely a "filebeat", és amely már tartalmazza a Kafka-ba korábban betolt adatokat. Beállítjuk a fogyasztói csoportot a group_id mezőben, amely egy vagy több feliratkozót tartalmaz, akik egyesítve olvassák a topicban lévő adatokat. Ez lehetővé teszi a Kafka számára, hogy a kiáramló adatokat egyenletesen eloszlassa a csoport tagjai között, biztosítva a terheléselosztást és elkerülve, hogy ugyanazt az üzenetet többször is elküldje ugyanannak a csoportnak.

Amikor a Filebeat fut, a következő kimenetet kell látnunk:

json
Copy code
"processed" => {

    "tags" => [
        "tags-for-everybody",
        "you-get-a-tag",
        "and-you-get-a-tag",
        "forwarded"
    ],
    "process" => {
        "program" => "sudo"
    },
    "message" => "pam_unix(sudo:session): session closed for user root",
    "syslog" => { ... }
}

Ez azt jelzi, hogy az eszköz a naplót a Kafka-ba küldte, majd a Logstash visszaolvasta azt és megjelenítette a képernyőn. A továbbiakban használhatunk különböző feldolgozókat, hogy módosítsuk az eseményeket a kívánt formátumban, vagy további címkéket adjunk hozzá a naplókhoz.

A folyamatok vezérlése érdekében a Filebeat képes feltételek megadására is, amelyek alapján a feldolgozók végrehajtódnak. Így például csak akkor módosíthatunk egy mezőt, ha annak értéke megfelel bizonyos kritériumoknak.

Hogyan konfiguráljunk Filebeat-et Zeek és Kafka integrációval?

A Filebeat rendszer konfigurálása akkor válik igazán fontossá, amikor a Filebeat-et több forrásból származó logok olvasására kell használni, például egy köztes kiszolgálón vagy egy landing pad-en futó Filebeat példányon. A Zeek, mint hálózati forgalom-elemző, magasabb jogosultságokat igényel ahhoz, hogy a hálózati interfészről hallgasson, és megfelelő módon védi a naplóit. Ezért az alábbi lépéseket érdemes követni.

Először is hozzá kell adni a felhasználónevünket a zeek csoporthoz. A következő parancs segítségével tehetjük ezt meg:

bash
Copy code
$ sudo usermod -aG zeek j

Ezt követően ki kell lépni a rendszerből, majd vissza, hogy a változások életbe lépjenek. Ha valamilyen okból nem érvényesülne a változás, futtassuk a groups parancsot, és ellenőrizzük az /etc/group fájl tartalmát, hogy meggyőződjünk róla, hogy a felhasználónév szerepel a zeek csoportban. Ha a felhasználónév nem található itt, használjuk a newgrp parancsot:

bash
Copy code
$ groups  

$ grep zeek /etc/group  
$ newgrp zeek

Ezután újra indíthatjuk a Filebeat-et, és figyelhetjük, ahogyan a konvertált naplók megjelennek a Logstash terminálban. Használjuk a következő parancsokat a konfiguráció és az output tesztelésére:

bash
Copy code
$ ./filebeat test config  
$ ./filebeat test output  
$ ./filebeat -e

A Filebeat a naplókat szépen konvertálja JSON formátumba, és a legtöbb kulcsfontosságú mezőt ECS (Elastic Common Schema) formátumban alakítja át. Például a Zeek naplókban a forrás IP és MAC cím, valamint a csomagok és byte-ok száma így nézhet ki:

json
Copy code
"source" => {  

    "mac" => "11:50:56:c4:00:a2",  
    "bytes" => 812,  
    "packets" => 4,  
    "port" => 62299,  
    "address" => "192.168.28.32",  
    "ip" => "192.168.28.32"  
},  
"@timestamp" => "2040-07-10T02:20:22.191Z"

Azonban a Filebeat modulok gyakran nem teljesen azonos módon végzik el a mezők konvertálását, különösen, ha az adott technológia bonyolultabb. Például a Cisco vagy Palo Alto Filebeat moduljai az Elasticsearch ingest pipeline-ra delegálják a bonyolultabb ECS konvertálásokat. A modulokban található processzorok lehetővé teszik, hogy a globális konfigurációkat ne kelljen túlterhelni több tucat vagy akár több száz sorral. Ezek a processzorok ugyanazon a szinten helyezkednek el, mint az engedélyezett és var.* beállítások, és a filebeat.yml fájlban globálisan definiált processzorokkal párhuzamosan futnak.

Például, ha szükséges, közvetlenül a fileset-ben is hozzáadhatunk címkéket. Az alábbi példa mutatja be, hogyan adhatunk hozzá címkéket a Zeek module-ban:

yaml
Copy code
modules.d/zeek.yml
1 connection:  
    enabled: true  
    var.paths: ["/opt/zeek/spool/zeek/conn.log"]  
2 input:  
    processors:  
        - add_tags:  
            tags: ["tag-in-connection-log"]

Itt egy új input mezőt adtunk hozzá, amely egy processzort tartalmaz. Ez a processzor címkét ad a kimenethez, és az eredmény így néz ki:

json
Copy code
"tags" => [  

    [0] "you-get-a-tag",  

    [1] "zeek.connection",  

    [2] "tag-in-connection-log"
]

A Filebeat nem képes egyszerre több output-ot kezelni, így érdemes már az elején jól meghatározni, hová küldjük az adatokat. Az output lehet Logstash, Elasticsearch, Kafka, vagy akár Redis is. Ha Kafka-t használunk, az adatokat témák segítségével küldhetjük ki, és a következő konfigurációra van szükség a Kafka-kapcsolathoz:

yaml
Copy code
output.kafka:  

  enabled: true  
  hosts: [ "kafka01:9092", "kafka02:9092" ]  
  topic: "filebeat"  
  client_id: "my-awesome-server-running-filebeat"
  headers:  
    - key: "category"  
      value: "remoteaccess"  
      when:  
        equals:  
          event.dataset: "zeek.ssh"
    - key: "category"  
      value: "web"  
      when:  
        equals:  
          event.dataset: "zeek.tls"

A Kafka-ban a client_id paraméter segít azonosítani a Filebeat-et futtató gépet, ami különösen hasznos lehet a hibaelhárítás során. A Kafka-fejlécek kulcs-érték párok formájában további metainformációkat adnak az üzenethez, például a kategóriát, ami segíthet a továbbítás során. A Filebeat elküldi az adatokat a megfelelő Kafka témába, és Logstash segítségével azok újra feldolgozhatók.

Ha Redis-t használunk üzenetközvetítőként, az integráció nagyon hasonlóan működik, mint a Kafka esetén. Itt is meg kell adni a hálózati beállításokat, a jelszót és az üzenet sorok kulcsait. Az alábbi példa bemutatja, hogyan állíthatjuk be a Redis kimenetet:

yaml
Copy code
output.redis:  

  enabled: true  
  hosts: ["localhost"]  
  password: "YOUR-REDIS-PASSWORD"  
  key: "filebeat"  
  keys:  
    - key: "remoteaccess"  
      when:  
        or:  
          - contains:  
              event.dataset: "zeek.ssh"

A Redis használata lehetővé teszi az üzenetek gyors továbbítását anélkül, hogy az adatokat közvetlenül Elasticsearch-ba küldenénk, ezáltal csökkentve a terhelést és biztosítva a gyors válaszidőket.

A fent említett konfigurációk megkönnyítik a logok áramlását és a rendszer stabilitását, különösen, ha nagy mennyiségű adatot kell kezelni. Mindezek mellett a megfelelő címkézés és az output kezelés alapvető fontosságú a rendszer karbantartása és a hibák gyors felderítése szempontjából.

Hogyan konfiguráljunk Rsyslogot Logstash-kal való integrációhoz

Az első lépésben figyeljünk arra, hogy a Rsyslog nem engedi a meglévő tulajdonságok felülírását, de lehetőség van új változók létrehozására. Ehhez a set parancsot használhatjuk. Például létrehozhatunk egy új változót $!tag_fixed, amely az aktuális syslog tag értékét tartalmazza, de a kernel szót helyettesíti popcorn-nal. Az új változót így egy új címkéhez rendeljük, amely hasznos lehet, ha standardizálni szeretnénk a naplókat, például az összes hosztnevet kisbetűssé alakítani.

A syslog üzenetek formázása és módosítása, mint a karakterek cseréje, különösen akkor fontos, amikor érzékeny adatokat kell eltüntetnünk, vagy ha az üzeneteket szabványosítani akarjuk. A re_match_i és a %msg:::drop-last-lf% módszerek lehetővé teszik, hogy további finomhangolást végezzünk a naplóüzenetek tartalmán, például érzéketlen összehasonlításokat végezzünk, vagy eltávolítsuk a sortöréseket.

Ezen kívül a Rsyslog egyszerűsíti a logok célzott irányítását, és lehetővé teszi az erőteljes szerkesztési funkciók alkalmazását. Az alábbiakban két konfigurációs példát ismertetünk: egy olyan kliens konfigurációt, amely a helyi naplókat küldi Logstash-ba, és egy központi Rsyslog szerver konfigurációját, amely fogadja a hálózati logokat, továbbítja azokat Logstash-ra, és egyúttal helyben is tárolja őket.

plaintext
Copy code
input {   
  tcp {       
    port => 51443     
    type => syslog     
    mode => server     
    ssl_enabled => true       
    ssl_client_authentication => "required"       
    ssl_certificate => "/wildcard.local.flex.cert.pem"       
    ssl_key => "/wildcard.local.flex.key.pem"       
    ssl_key_passphrase => "abcd1234"       
    ssl_certificate_authorities => ["/ca-chain.cert.pem"]   
  } 
}
output {   
  stdout { codec => rubydebug }   
  elasticsearch {       
    id => "elasticsearch-output"       
    hosts => "https://elasticsearch01.local:9200"       
    api_key => "kwouKo0BFSso9JQdUCJj:ANI6NTBMQx2NNDj3UIAxkw"       
    data_stream => true       
    ssl_enabled => true       
    ssl_certificate => "/wildcard.local.flex.cert.pem"       
    ssl_key => "/wildcard.local.flex.key.nopass.pem"       
    ssl_certificate_authorities => ["/ca-chain.cert.pem"]   
  } 
}

Ezután egy egyszerű Rsyslog kliens konfigurációt hozunk létre, amely a helyi naplókat küldi Logstash-ba. Az alábbi konfigurációban a client.conf fájlban a TLS kapcsolati beállításokkal küldjük el a logokat:

plaintext
Copy code
global(

  defaultNetstreamDriverCAFile="/etc/ssl/rsyslog/ca-chain.cert.pem"
  defaultNetstreamDriverCertFile="/etc/ssl/rsyslog/rsyslog.local.flex.cert.pem"
  defaultNetstreamDriverKeyFile="/etc/ssl/rsyslog/rsyslog.local.flex.key.nopass.pem"
)
action(
  type="omfwd"
  protocol="tcp"
  target="logstash.local"
  port="51443"
  streamDriver="ossl"
  streamDriverMode="1"
  streamDriverAuthMode="x509/name"
  streamDriverPermittedPeers="logstash,logstash.local"
)

Ha a célunk egy központi loggyűjtő rendszer kiépítése, amely fogadja a hálózati naplókat, továbbítja azokat Logstash-ra, és helyben is tárolja őket, a következő konfigurációval dolgozhatunk. Ehhez először be kell töltenünk az imtcp modult és beállítani a megfelelő TLS titkosítást:

plaintext
Copy code
module(

  load="imtcp"
  streamdriver.name="ossl"
  streamdriver.mode="1"
  streamdriver.authmode="x509/name"
)
input(type="imtcp" port="5443" ruleset="myrules")

A myrules szabályrendszer segítségével az Rsyslog külön fájlokba menti a tűzfal (UFW) eseményeket és a többi eseményt is a megfelelő naplókba, majd továbbítja őket Logstash-ba. Az alábbiakban látható, hogyan definiálhatjuk a fájlok elérési útvonalait és az akciókat:

plaintext
Copy code
template(name="firewallfile" type="string" string="/var/log/network/firewall-%hostname%.log")

template(name="hostnamefile" type="string" string="/var/log/network/%hostname%.log")
ruleset(name="myrules") {
  if $msg contains_i "[UFW " then {
    action(type="omfile" FileCreateMode="0640" dynaFile="firewallfile")
  }
  else {
    action(type="omfile" FileCreateMode="0640" dynaFile="hostnamefile")
  }
  action(
    type="omfwd"
    protocol="tcp"
    target="logstash.local"
    port="51443"
    streamDriver="ossl"
    streamDriverMode="1"
    streamDriverAuthMode="x509/name"
    streamDriverPermittedPeers="logstash,logstash.local"
  )
}

Ez a konfiguráció lehetővé teszi a tűzfal események és más típusú üzenetek külön kezelését, valamint biztosítja a biztonságos adatátvitelt a Logstash rendszer felé.

Mindezek a konfigurációk segítenek a hálózati naplók biztonságos és hatékony gyűjtésében, továbbításában és tárolásában. Rsyslog és Logstash integrációja lehetővé teszi a naplók valós idejű feldolgozását, és az adatokat rugalmasan irányíthatjuk különböző célállomások felé, mint például Elasticsearch, ami alapvető fontosságú a naplóelemzési és monitoring rendszerek számára.

Hogyan automatizálható a hálózati szolgáltatások kezelése Ansible segítségével?

A hálózati szolgáltatások kezelésének automatizálása számos előnnyel jár, különösen akkor, ha nagy mennyiségű adatot és szolgáltatást kell kezelni egy szervezeten belül vagy kívül. Az Ansible és a Python segítségével egyszerűen létrehozhatók olyan API-k, amelyek lehetővé teszik a különböző alkalmazások közötti adatkommunikációt. Az alábbiakban bemutatok egy egyszerű példát, amely segít megérteni, hogyan használhatjuk az Ansible-t és egy Python alapú Flask szervert az API-k kezelésére.

python
Copy code
@app.route('/new_api_request')
def requestapipage():
    message = {"new_key":"b33fb33f"}
    return json.dumps(message)
@app.route('/validate', methods=['POST'])
def validateapipage():
    d = request.get_json(force=True)
    api_key = d["api_key"]
    return json.dumps({"status":"valid"})
@app.route('/api/fleet/outputs', methods=['POST'])
def fleetapipage():
    d = request.get_json(force=True)
    return json.dumps(d)

A következő Ansible playbook segítségével bemutathatjuk, hogyan lehet interakcióba lépni az API-kkal:

yaml
Copy code
- hosts: localhost
  become: no
  gather_facts: no
  tasks:

    - name: Get Simulated API Key

      uri:
        validate_certs: false
        method: GET
        url: https://localhost:5000/new_api_request
        http_agent: "curl/7.81.0"
        return_content: true
      register: api_result_unparsed
    - name: Parse API Key from JSON, Set Fact
      set_fact:
        api_key: "{{ (api_result_unparsed.content|from_json).new_key }}"
        cacheable: yes
    - name: Show API Key
      debug:
        msg: "{{ ansible_facts['api_key'] }}"
    - name: Save Facts - API Key Only
      local_action: copy content="{{ ansible_facts['api_key'] }}" dest="logs/api_{{ ansible_host }}"

    - name: Validate API Key

      uri:
        method: POST
        url: https://localhost:5000/validate
        validate_certs: false
        headers:
          Content-Type: application/json
        return_content: true
        body_format: json
        body: {"api_key":"{{ansible_facts['api_key']}}"}
      register: validate_response
    - name: Show Validation Status
      debug:
        var: (validate_response.content|from_json).status

A playbook egy HTTP GET kérést küld a Flask szervernek, hogy lekérje az API kulcsot, majd azt JSON formátumban feldolgozza, hogy beállítson egy változót. Ezt követően egy POST kérést küld a szerverre, hogy validálja az API kulcsot. Az eredményt a playbook visszaadja, és a válasz státusza megjelenik. Az Ansible lehetővé teszi, hogy az egész folyamatot automatizáljuk, így egyetlen parancs végrehajtásával egyszerűen tesztelhetjük az API végpontok működését.

Egy másik hasznos eszköz, amelyet az API-val való munka során használhatunk, az HTTP alapú hitelesítés. A következő JSON példát mutatja be, amely a Kibana API beállításait tartalmazza, és amelyet HTTP POST kérésekkel távolról küldhetünk el:

json
Copy code
{

  "type": "elasticsearch",
  "id": "fleet-elasticsearch",
  "name": "elasticsearch",
  "hosts": ["https://elasticsearch.local:9200"],

  "is_default": true,

  "is_default_monitoring": true,
  "ssl": {

    "certificate": "/opt/Elastic/Agent/certs/wildcard.local.flex.cert.pem",

    "key": "/opt/Elastic/Agent/certs/wildcard.local.flex.key.pem",

    "certificate_authorities": ["/opt/Elastic/Agent/certs/ca-chain.cert.pem"]

  }
}

A Kibana API alapú hitelesítés használata érdekében az alábbi Ansible playbookot alkalmazhatjuk:

yaml
Copy code
- hosts: localhost
  become: no
  gather_facts: no
  tasks:

    - name: Update Fleet Default Outputs and TLS Filepaths (POST)

      delegate_to: localhost
      run_once: true
      uri:
        method: POST
        url: https://127.0.0.1:5000/api/fleet/outputs
        force_basic_auth: true
        user: elastic
        password: abcd1234
        validate_certs: false
        headers:
          kbn-xsrf: reporting
          Content-Type: application/json
        return_content: true
        body_format: json
        body: "{{lookup('file','files/fleet_output_elasticsearch.json') | to_json}}"
      register: api_output
    - name: Show Results
      debug:
        var: api_output.content|from_json

Ez a playbook HTTP alapú hitelesítést alkalmaz a Kibana API-hoz való hozzáféréshez. A felhasználónév és jelszó megadásával biztonságosan végrehajthatjuk az API kéréseket anélkül, hogy problémát okozna a hitelesítés.

Fontos, hogy a hálózati szolgáltatások automatizálásakor a megfelelő biztonsági intézkedéseket is figyelembe vegyük, például SSL/TLS titkosítást és hitelesítést, hogy megvédjük az adatainkat a jogosulatlan hozzáféréstől. Emellett fontos, hogy a rendszer monitorozása is része legyen a folyamatnak, hogy időben észlelhessük a problémákat.