Mai 2024
Autor:in des Beitrags
Kevin
Senior Consultant
Veröffentlicht am
08.05.2024 von Kevin
Jetzt Blogbeitrag teilen
Xing LinkedIn Facebook Twitter
NETSCALER LOG UND METRIK ANALYTICS SERVER

Teil 2: Bereitstellung Elastic Stack und Anbindung der NetScaler Syslogs

Na, wer hat’s vermisst? Bevor wir richtig loslegen, lasst uns kurz zurückblicken: Im letzten Kapitel haben wir unseren Analytics Server auf Trab gebracht und sind nun bereit für den nächsten Schritt. Heute steht der Elastic Stack auf dem Plan – Kibana, Elasticsearch und Logstash stehen in den Startlöchern. Wir wollen diese Burschen zum Laufen bringen, damit sie fleißig Logs sammeln und analysieren können. Also, keine Zeit verlieren, lasst uns loslegen!

Wir klopfen an der Tür unseres Hosts und betreten ihn mit SSH. Dann spazieren wir in unser Projektverzeichnis (cd /srv/lumas), wo wir einen neuen Ordner namens “elastic_stack” erstellen (sudo mkdir elastic_stack) und sofort hineinhüpfen (cd elastic_stack). Doch bevor wir den Elastic Stack zum Leben erwecken können, benötigen wir eine magische Datei namens Docker-Compose (sudo touch docker-compose.yml). Also öffnen wir sie mit einem Hauch von Magie (sudo vim docker-compose.yml). In diesem Moment zaubern wir den folgenden Inhalt hinein:

version: "3.8"
services:
  setup:
    image: docker.elastic.co/elasticsearch/elasticsearch:${STACK_VERSION}
    volumes:
      - certs:/usr/share/elasticsearch/config/certs
    user: "0"
    command: >
      bash -c '
        if [ x${ELASTIC_PASSWORD} == x ]; then
          echo "Set the ELASTIC_PASSWORD environment variable in the .env file";
          exit 1;
        elif [ x${KIBANA_PASSWORD} == x ]; then
          echo "Set the KIBANA_PASSWORD environment variable in the .env file";
          exit 1;
        fi;
        if [ ! -f config/certs/ca.zip ]; then
          echo "Creating CA";
          bin/elasticsearch-certutil ca --silent --pem -out config/certs/ca.zip;
          unzip config/certs/ca.zip -d config/certs;
        fi;
        if [ ! -f config/certs/certs.zip ]; then
          echo "Creating certs";
          echo -ne \
          "instances:\n"\
          "  - name: es01\n"\
          "    dns:\n"\
          "      - es01\n"\
          "      - localhost\n"\
          "    ip:\n"\
          "      - 127.0.0.1\n"\
          "  - name: es02\n"\
          "    dns:\n"\
          "      - es02\n"\
          "      - localhost\n"\
          "    ip:\n"\
          "      - 127.0.0.1\n"\
          "  - name: es03\n"\
          "    dns:\n"\
          "      - es03\n"\
          "      - localhost\n"\
          "    ip:\n"\
          "      - 127.0.0.1\n"\
          > config/certs/instances.yml;
          bin/elasticsearch-certutil cert --silent --pem -out config/certs/certs.zip --in config/certs/instances.yml --ca-cert config/certs/ca/ca.crt --ca-key config/certs/ca/ca.key;
          unzip config/certs/certs.zip -d config/certs;
        fi;
        echo "Setting file permissions"
        chown -R root:root config/certs;
        find . -type d -exec chmod 750 \{\} \;;
        find . -type f -exec chmod 640 \{\} \;;
        echo "Waiting for Elasticsearch availability";
        until curl -s --cacert config/certs/ca/ca.crt https://es01:9200 | grep -q "missing authentication credentials"; do sleep 30; done;
        echo "Setting kibana_system password";
        until curl -s -X POST --cacert config/certs/ca/ca.crt -u "elastic:${ELASTIC_PASSWORD}" -H "Content-Type: application/json" https://es01:9200/_security/user/kibana_system/_password -d "{\"password\":\"${KIBANA_PASSWORD}\"}" | grep -q "^{}"; do sleep 10; done;
        echo "All done!";
      '
    healthcheck:
      test: ["CMD-SHELL", "[ -f config/certs/es01/es01.crt ]"]
      interval: 1s
      timeout: 5s
      retries: 120
  es01:
    depends_on:
      setup:
        condition: service_healthy
    image: docker.elastic.co/elasticsearch/elasticsearch:${STACK_VERSION}
    volumes:
      - certs:/usr/share/elasticsearch/config/certs
      - esdata01:/usr/share/elasticsearch/data
    ports:
      - ${ES_PORT}:9200
    environment:
      - node.name=es01
      - cluster.name=${CLUSTER_NAME}
      - cluster.initial_master_nodes=es01,es02,es03
      - discovery.seed_hosts=es02,es03
      - ELASTIC_PASSWORD=${ELASTIC_PASSWORD}
      - bootstrap.memory_lock=true
      - xpack.security.enabled=true
      - xpack.security.http.ssl.enabled=true
      - xpack.security.http.ssl.key=certs/es01/es01.key
      - xpack.security.http.ssl.certificate=certs/es01/es01.crt
      - xpack.security.http.ssl.certificate_authorities=certs/ca/ca.crt
      - xpack.security.transport.ssl.enabled=true
      - xpack.security.transport.ssl.key=certs/es01/es01.key
      - xpack.security.transport.ssl.certificate=certs/es01/es01.crt
      - xpack.security.transport.ssl.certificate_authorities=certs/ca/ca.crt
      - xpack.security.transport.ssl.verification_mode=certificate
      - xpack.license.self_generated.type=${LICENSE}
      - '/etc/localtime:/etc/localtime:ro'
    mem_limit: ${ES_MEM_LIMIT}
    ulimits:
      memlock:
        soft: -1
        hard: -1
    healthcheck:
      test:
        [
          "CMD-SHELL",
          "curl -s --cacert config/certs/ca/ca.crt https://localhost:9200 | grep -q 'missing authentication credentials'",
        ]
      interval: 10s
      timeout: 10s
      retries: 120
  es02:
    depends_on:
      es01:
        condition: service_healthy
    image: docker.elastic.co/elasticsearch/elasticsearch:${STACK_VERSION}
    volumes:
      - certs:/usr/share/elasticsearch/config/certs
      - esdata02:/usr/share/elasticsearch/data
    environment:
      - node.name=es02
      - cluster.name=${CLUSTER_NAME}
      - cluster.initial_master_nodes=es01,es02,es03
      - discovery.seed_hosts=es01,es03
      - bootstrap.memory_lock=true
      - xpack.security.enabled=true
      - xpack.security.http.ssl.enabled=true
      - xpack.security.http.ssl.key=certs/es02/es02.key
      - xpack.security.http.ssl.certificate=certs/es02/es02.crt
      - xpack.security.http.ssl.certificate_authorities=certs/ca/ca.crt
      - xpack.security.transport.ssl.enabled=true
      - xpack.security.transport.ssl.key=certs/es02/es02.key
      - xpack.security.transport.ssl.certificate=certs/es02/es02.crt
      - xpack.security.transport.ssl.certificate_authorities=certs/ca/ca.crt
      - xpack.security.transport.ssl.verification_mode=certificate
      - xpack.license.self_generated.type=${LICENSE}
      - '/etc/localtime:/etc/localtime:ro'
    mem_limit: ${ES_MEM_LIMIT}
    ulimits:
      memlock:
        soft: -1
        hard: -1
    healthcheck:
      test:
        [
          "CMD-SHELL",
          "curl -s --cacert config/certs/ca/ca.crt https://localhost:9200 | grep -q 'missing authentication credentials'",
        ]
      interval: 10s
      timeout: 10s
      retries: 120
  es03:
    depends_on:
      es02:
        condition: service_healthy
    image: docker.elastic.co/elasticsearch/elasticsearch:${STACK_VERSION}
    volumes:
      - certs:/usr/share/elasticsearch/config/certs
      - esdata03:/usr/share/elasticsearch/data
    environment:
      - node.name=es03
      - cluster.name=${CLUSTER_NAME}
      - cluster.initial_master_nodes=es01,es02,es03
      - discovery.seed_hosts=es01,es02
      - bootstrap.memory_lock=true
      - xpack.security.enabled=true
      - xpack.security.http.ssl.enabled=true
      - xpack.security.http.ssl.key=certs/es03/es03.key
      - xpack.security.http.ssl.certificate=certs/es03/es03.crt
      - xpack.security.http.ssl.certificate_authorities=certs/ca/ca.crt
      - xpack.security.transport.ssl.enabled=true
      - xpack.security.transport.ssl.key=certs/es03/es03.key
      - xpack.security.transport.ssl.certificate=certs/es03/es03.crt
      - xpack.security.transport.ssl.certificate_authorities=certs/ca/ca.crt
      - xpack.security.transport.ssl.verification_mode=certificate
      - xpack.license.self_generated.type=${LICENSE}
      - '/etc/localtime:/etc/localtime:ro'
    mem_limit: ${ES_MEM_LIMIT}
    ulimits:
      memlock:
        soft: -1
        hard: -1
    healthcheck:
      test:
        [
          "CMD-SHELL",
          "curl -s --cacert config/certs/ca/ca.crt https://localhost:9200 | grep -q 'missing authentication credentials'",
        ]
      interval: 10s
      timeout: 10s
      retries: 120
  kibana:
    depends_on:
      es01:
        condition: service_healthy
      es02:
        condition: service_healthy
      es03:
        condition: service_healthy
    image: docker.elastic.co/kibana/kibana:${STACK_VERSION}
    restart: unless-stopped
    labels:
      co.elastic.logs/module: kibana
    volumes:
      - certs:/usr/share/kibana/config/certs
      - kibanadata:/usr/share/kibana/data
    ports:
      - ${KIBANA_PORT}:5601
    environment:
      - SERVERNAME=kibana
      - ELASTICSEARCH_HOSTS=https://es01:9200
      - ELASTICSEARCH_USERNAME=kibana_system
      - ELASTICSEARCH_PASSWORD=${KIBANA_PASSWORD}
      - ELASTICSEARCH_SSL_CERTIFICATEAUTHORITIES=config/certs/ca/ca.crt
      - XPACK_SECURITY_ENCRYPTIONKEY=${ENCRYPTION_KEY}
      - XPACK_ENCRYPTEDSAVEDOBJECTS_ENCRYPTIONKEY=${ENCRYPTION_KEY}
      - XPACK_REPORTING_ENCRYPTIONKEY=${ENCRYPTION_KEY}
      - '/etc/localtime:/etc/localtime:ro'
    mem_limit: ${KB_MEM_LIMIT}
    healthcheck:
      test:
        [
          "CMD-SHELL",
          "curl -s -I http://localhost:5601 | grep -q 'HTTP/1.1 302 Found'",
        ]
      interval: 10s
      timeout: 10s
      retries: 120
  logstash01:
    depends_on:
      es01:
        condition: service_healthy
      es02:
        condition: service_healthy
      es03:
        condition: service_healthy
      kibana:
        condition: service_healthy
    image: docker.elastic.co/logstash/logstash:${STACK_VERSION}
    restart: unless-stopped
    ports:
      - "1514:1514/udp"
    labels:
      co.elastic.logs/module: logstash
    user: root
    volumes:
      - certs:/usr/share/logstash/certs
      - logstashdata01:/usr/share/logstash/data
      - "/srv/lumas/elastic_stack/data/logstash/ingest_data/:/usr/share/logstash/ingest_data/"
      - "/srv/lumas/elastic_stack/data/logstash/config/pipelines.yml:/usr/share/logstash/config/pipelines.yml:ro,z"
      - "/srv/lumas/elastic_stack/data/logstash/pipeline:/usr/share/logstash/pipeline:ro,z"
      - '/etc/localtime:/etc/localtime:ro'
    environment:
      - xpack.monitoring.enabled=false
      - ELASTIC_USER=elastic
      - ELASTIC_PASSWORD=${ELASTIC_PASSWORD}
      - ELASTIC_HOSTS=https://es01:9200
    mem_limit: ${LS_MEM_LIMIT}
networks:
  default:
    name: lumas
    external: true
volumes:
  certs:
    driver: local
  esdata01:
    driver: local
  esdata02:
    driver: local
  esdata03:
    driver: local
  kibanadata:
    driver: local
  logstashdata01:
    driver: local

 

Um unser Werk zu sichern, zaubern wir einen kleinen Zaubertrick herbei: Wir drücken ESC und dann :x! und geben ein magisches Enter hinzu, um alles zu speichern. Jetzt brauchen wir noch ein Environmentfile. Also legen wir eins an (sudo touch .env) und öffnen es mit einem weiteren Zaubertrick namens sudo vim .env. Jetzt hauchen wir folgenden Inhalt hinein:

# Project namespace (defaults to the current folder name if not set)
COMPOSE_PROJECT_NAME=lumas
# Password for the 'elastic' user (at least 6 characters)
ELASTIC_PASSWORD=D3m03l4st1c!
# Password for the 'kibana_system' user (at least 6 characters)
KIBANA_PASSWORD=K1b4n4!
# Version of Elastic products
STACK_VERSION=8.12.0
# Set the cluster name
CLUSTER_NAME=-lumas-cluster
# Set to 'basic' or 'trial' to automatically start the 30-day trial
LICENSE=basic
#LICENSE=trial
# Port to expose Elasticsearch HTTP API to the host
ES_PORT=9200
# Port to expose Kibana to the host
KIBANA_PORT=5601
# Increase or decrease based on the available host memory (in bytes)
ES_MEM_LIMIT=4294967296
KB_MEM_LIMIT=2000000000
LS_MEM_LIMIT=2000000000
# SAMPLE Predefined Key only to be used in POC environments
ENCRYPTION_KEY=c34d38b3a14956121ff2170e5030b471551370178f43e5626eec58b04a30fae2

 

Für die finale Berührung unseres Zauberspruchs, wiederholen wir den magischen ESC, gefolgt von :x! und einem entscheidenden Enter, um alles zu sichern. Bitte denkt daran, die Passwörter in Zeile 4 und 6 sowie den Encryption Key in Zeile 23 nach euren eigenen Wünschen anzupassen. Ihr könnt auch die Werte in den Zeilen 2 und 10 nach eurem Belieben anpassen. Nun brauchen wir noch eine kleine Ordnerstruktur die so aussehen soll:

Für unsere Ordnerstruktur geben wir diesen folgende befehle ein:

# Erstellen "data" Ordner
sudo mkdir data
# Erstellen der Logstash ordner Struktur
sudo mkdir -p ./data/logstash/ingest_data
sudo mkdir -p ./data/logstash/config
sudo mkdir -p ./data/logstash/pipeline

Als nächstes zaubern wir eine Logstash-Pipeline für die NetScaler ADC Syslogs herbei. Dazu erstellen wir eine Datei namens ‘netscaler-adc-syslog-logstash.conf’ im Pipeline-Ordner und öffnen sie mit VIM.

#Anlegen des Konfigurationsfiles
sudo touch ./data/logstash/pipeline/netscaler-adc-syslog-logstash.conf
# Öffnen des Konfigurationsfiles
sudo vim ./data/logstash/pipeline/netscaler-adc-syslog-logstash.conf

In diese Datei fügen wir eine Pipeline ein, die auf dem UDP-Port 1514 lauscht, eine grundlegende Analyse durchführt und die Daten dann an Elasticsearch sendet. Der Index wird dabei “netscaler_adc_syslog_<Heutiges Datum>” benannt.

input {
  udp {
    port => 1514
    type => "netscaler"
  }
}
filter {
  grok {
    ecs_compatibility => "v1"
    break_on_match => true
    match => {
      "message" => [
        "^<%{POSINT:syslog_pri}>\s+%{DATE_US:log_date}:%{TIME:log_time}\s+GMT\s+%{SYSLOGHOST:syslog_hostname}\s+%{DATA:netscaler_tag}\s+:\s+%{DATA}\s+%{WORD:subsystem}\s+%{WORD:subsystem_event}\s+%{DATA:subsystem_event_process_id}\s+%{DATA:subsystem_event_message_id}\s+:\s+%{GREEDYDATA:subsystem_message}"
      ]  
    }
  }
  syslog_pri {  }
}
output {
  elasticsearch {
    index => "netscaler_adc_syslog_%{+YYYY_MM_dd}"
    hosts => "${ELASTIC_HOSTS}"
    user => "${ELASTIC_USER}"
    password => "${ELASTIC_PASSWORD}"
    cacert => "certs/ca/ca.crt"
    data_stream => "false"
  }
}

Um sicherzustellen, dass unsere Pipeline verwendet wird, erstellen wir eine Konfigurationsdatei. Diese Datei sagt Logstash, dass die erstellte Pipeline geladen werden soll.

# Konfigurationsfile anlegen
sudo touch ./data/logstash/config/pipelines.yml
# Öffnen mit VIM
sudo vim ./data/logstash/config/pipelines.yml

Die Konfigurationsdatei erhält folgenden Inhalt und wird gespeichert.

- pipeline.id: netscaler_adc_syslog
  path.config: "/usr/share/logstash/pipeline/netscaler-adc-syslog-logstash.conf"

Super, jetzt sind wir bereit! Wir laden die Docker-Images herunter und starten das Docker-Compose-File.

# Images herunterladen
sudo docker-compose pull
# Elastic Stack starten
sudo docker-compose up -d

Der Elastic Stack ist in Gang gesetzt! Keine Panik… das dauert ein wenig. Wenn der Elastic Stack vollständig gestartet ist, zeigt der Output von sudo docker ps -a folgendes an:

Alles klar, dass der Container mit dem Namen “lumas_setup_1” im Zustand “Exited” ist, ist in Ordnung.

Jetzt heißt es, noch fünf Minuten warten, und dann könnt ihr Kibana über “http://<IP-Adresse eures Servers>:5601” öffnen.

Für den Zugang verwenden wir den Benutzernamen “elastic” und das Passwort, das in Zeile 4 des .env-Files definiert wurde (in meinem Fall ELASTIC_PASSWORD=D3m03l4st1c!).

Wenn der Login erfolgreich ist, haben wir es geschafft! Wir haben einen Elastic Stack bereitgestellt, bei dem Logstash an die Elasticsearch Node 1 sendet und Kibana mit dieser Node kommuniziert. Die Nodes 2 und 3 sind in diesem Fall lediglich für die Datenverteilung und Performance gedacht.

Natürlich ist mir bewusst, dass man alle drei Elasticsearch-Knoten für Kibana und Logstash nutzen kann, aber für unseren Anwendungsfall ist dies ausreichend.

Damit unser Speicher nicht überquillt, machen wir jetzt ‘nen Plan: Index Lifecycle Policy! Das bedeutet, alte Logs weg damit. Wie? Easy! Einfach über Kibanas Dev Tools den Trick mit dem Request: ‘Lösch mal Indexe, die älter als 10 Tage sind.’ Natürlich könnt ihr auch ‘nen anderen Zeitraum wählen, ganz wie ihr wollt.

PUT _ilm/policy/netscaler_adc_syslog
{
  "policy": {
    "phases": {
      "hot": {
        "min_age": "0ms",
        "actions": {
          "set_priority": {
            "priority": 100
          }
        }
      },
      "delete": {
        "min_age": "10d",
        "actions": {
          "delete": {
            "delete_searchable_snapshot": true
          }
        }
      }
    }
  }
}

Aber damit unser Plan auch auf die Indexe von Logstash erstellt werden zutrifft, brauchen wir ‘nen Index Template. Auch das ist ein Klacks! Wir hauen das Ding einfach über die Dev Tools rein mit diesem Request.

PUT _index_template/netscaler_adc_syslog
{
  "index_patterns": ["netscaler_adc_syslog_*"],
  "priority": 1,
  "template": {
    "settings": {
      "index.lifecycle.name": "netscaler_adc_syslog",
      "index.lifecycle.rollover_alias": "_netscaler_adc_syslog",
      "index.routing.allocation.include._tier_preference": "data_content",
      "index.refresh_interval": "1s",
      "index.number_of_shards": "2",
      "index.number_of_replicas": "1"
    },
    "aliases": {}
  }
}

Los geht’s! Zeit, am NetScaler zu werkeln. Wir basteln ‘ne Standard Syslog Policy, die die Syslogs ab ins Logstash schubst.

add audit syslogAction syslog_act_syslog_linux-host_01 <IP vom Linux Host> -serverPort 1514 -logLevel ALL -managementlog ALL -mgmtlogLevel ALL
add audit syslogPolicy syslog_pol_syslog_linux-host_01 true syslog_act_syslog_linux-host_01
bind audit syslogGlobal -policyName syslog_pol_syslog_linux-host_01 -priority 100

Easy peasy! Ihr könnt das passende Loglevel nach euren Vorlieben festlegen. Und wenn alles glatt läuft, dann späht mal ins Index Management rein – da solltet ihr ‘nen frischen Index erblicken.

Perfekt! Jetzt, wo die Logs im Elasticsearch liegen und mit einer schicken Lifecycle Policy versehen sind, brauchen wir nur noch ‘ne Aussicht, oder? Zurück ins Menü, rein ins Stack Management und ab zu den Kibana Dataviews

Los geht’s! Wir machen uns daran, eine zu erstellen. Einfach auf den “Create data view” Button drücken und loslegen.

Ganz nach Belieben! Wir geben ihr ‘nen Namen, den ihr frei wählen könnt, und das Index Pattern lautet netscaler_adc_syslog_*. Dann ab damit in die Speicherung.

Voilà! Jetzt könnt ihr die Logs begutachten und durchforsten, und das über die Discover Funktion.

Da habt ihr’s! Wählt einfach oben links die gerade erstellte View aus, und schon könnt ihr die Logs begutachten und durchsuchen. Easy peasy!

Perfekt! Die ersten Logs sind sicher im Kibana gelandet und bereit zur Bearbeitung. Im nächsten Teil machen wir uns daran, Prometheus und den NetScaler Observability Exporter aufzusetzen. Dann kriegen wir auch die Transaction Logs ins Kibana und speichern die Metriken schön ordentlich in Prometheus.

Es bleibt spannend!

Kontakt

Ihr persönlicher Ansprechpartner

Wir stehen Ihnen gerne zur Verfügung, um Ihre Fragen zu beantworten und Sie auf Ihrem Weg zu einer optimalen ADC-Lösung zu unterstützen.

MAXIMILIAN LEIMGRUBER | Team Lead Business Apps & KI und App Delivery

+49 89  71040920

maximilian@provectus.de

Termin vereinbaren

Zum Kontaktformular

Wollen Sie immer up2date sein? Dann melden Sie sich jetzt zu unserem Newsletter an

Bleiben Sie auf dem Laufenden. Wir informieren Sie regelmäßig über aktuelle Trends und technologische Neuerungen sowie geplante Webinare und Events. Sie erhalten Einblick in interessante Kundenprojekte und werfen einen Blick hinter die Kulissen. Melden Sie sich jetzt an.

Zur Newsletter Anmeldung 

Blogbeitrag

Citrix Long-Term Service Release 2402, jetzt mit CU1 Bug-Fix

In diesem Blog erfahren Sie, welche Mehrwerte das Citrix LTSR 2402 mitbringt und welcher Bug mit CU1 gefixt wurde.
Weiterlesen
Blogbeitrag

Änderungen bei der Lizenzüberwachung und Telemetrie von NetScaler und NetScaler-Console

Im letzten Jahr hat die Cloud Software Group im Bereich von Citrix die Erfassung von Telemetriedaten eingeführt. Ähnliches folgt nun auch im Bereich der NetScaler. Wär erklären, was jetzt zu tun ist!
Weiterlesen
Webinar

Webinar: Muss es denn immer gleich KI sein?

Kostenloses Webinar für IT-Entscheider*innen: Steigerung der Effizienz, Produktivität und Mitarbeiterzufriedenheit, im Spannungsfeld zwischen New Work, KI und Prozessautomatisierung.
Weiterlesen
Blogbeitrag

Wie Sie mit einem geregelten Prozess für Evergreening die Vorteile von Microsoft 365 optimal nutzen können

Wir zeigen, wie Sie mit Evergrenning Änderungen in Microsoft 365 optimal für Ihr Unternehmen nutzen können.
Weiterlesen
Blogbeitrag

Datenexfiltration in M365 mit Entra ID Conditional Access blockieren

In diesem Artikel taucht unser Experte in die Funktionen aus Conditional Access ein: “app enforced restrictions” und „Conditional Access App Control“ (CAAC).
Weiterlesen
Blogbeitrag

Startschuss für eine neue Geschäftsführung

Wir erweitern die Geschäftsführung und stellen unser neues Führungstrio vor.
Weiterlesen
Echt Ich

Echt Ich Christian

In ECHT ICH erfahrt ihr mehr über Christian, seinen Arbeitsalltag, seine Hobbys und warum er bei Provectus “ECHT ER” sein kann.
Weiterlesen
Blogbeitrag

M365 Compliance Whitepaper

In unserem Whitepaper nehmen wir die Bereiche Datenschutz und Compliance unter die Lupe und geben Ihnen wertvolle Handlungsempfehlungen.
Weiterlesen
Blogbeitrag

Microsoft Power Platform – ja oder nein?

Erfahren Sie, wie Sie die Vorteile und Risiken der Microsoft Power Platform abwägen und die beste Lösung für Ihre Anforderungen finden.
Weiterlesen
Blogbeitrag

M365 Compliance Quick-Assessment

Mit unserem Quick Assessment können Sie einige der typischen Fallstricke zu beleuchten im Themenkomplex „Compliance und Datenschutz und M365″.
Weiterlesen
Jetzt Blogbeitrag teilen
Xing LinkedIn Facebook Twitter