Condividi tramite

Microsoft Sentinel per SAP in Azure

  • Articolo

Questo articolo fa parte della serie di articoli "Sap extend and innovazione security: Best practices".

Questo articolo illustra le considerazioni chiave sulla progettazione per la distribuzione degli agenti usando la soluzione Microsoft Sentinel per applicazioni SAP, server applicazioni SAP, server di database SAP HANA e regole di Microsoft Sentinel.

Prerequisiti per questo scenario:

  • Per raccogliere i dati dai sistemi SAP, è necessario distribuire un connettore SAP di Microsoft Sentinel.
  • È necessario distribuire un connettore separato per ogni combinazione SID (SAP Security Identifier) e numero client.

Considerazioni relative alla progettazione

Vedere le considerazioni di progettazione seguenti per ogni componente.

Soluzione Microsoft Sentinel per applicazioni SAP

  • La topologia dell'architettura SAP può avere più prodotti SAP distribuiti tra più ID di sistema, client e numeri di istanza. L'architettura potrebbe avere diversi server ABAP front-end, ma richiede solo una connessione server ABAP. Prendere in considerazione la connessione al server messaggi SAP, che indirizza il connettore al server ABAP corretto e raccoglie i dati per il sistema SAP.

  • Il connettore viene distribuito come contenitore Docker in una macchina virtuale host o in un server fisico. Il contenitore del connettore supporta la distribuzione in un computer locale e in una macchina virtuale basata su Azure. Il connettore dati non supporta una configurazione a disponibilità elevata predefinita. Se lo scenario richiede un'opzione a disponibilità elevata, è consigliabile distribuire il contenitore del connettore in un cluster Kubernetes o in servizio Azure Kubernetes (servizio Azure Kubernetes).

    Per la configurazione dettagliata del servizio Azure Kubernetes, vedere Distribuire Microsoft Sentinel Threat Monitoring per un agente SAP in un servizio Azure Kubernetes o in un cluster Kubernetes.

    Nota

    È possibile ottenere una disponibilità elevata solo per il connettore dati usando un servizio Azure Kubernetes o una distribuzione kubernetes.

  • Un cluster Kubernetes supporta solo un singolo connettore dati che recupera i dati da un sistema SAP e invia i dati a un'unica area di lavoro Log Analytics. Se si eseguono più pod in un cluster Kubernetes che si connette allo stesso sistema SAP e si inviano dati alla stessa area di lavoro Log Analytics, vengono inviate più copie dei dati, che potrebbero comportare un aumento degli addebiti per la conservazione dei dati.

  • Quando si usano contenitori Docker, tutti i dati di un sistema SAP vengono inseriti in un'unica area di lavoro Log Analytics.

  • Il server che ospita gli agenti del connettore deve connettersi a tutti i server ABAP che richiedono il recupero dei dati. Ad esempio, il connettore deve instradare e connettersi ai server ABAP di destinazione usando le porte. Per altre informazioni, vedere Prerequisiti di distribuzione per le soluzioni Microsoft Sentinel per SAP.

  • Usare avvisi di Microsoft Sentinel, ad esempio Microsoft Teams, posta elettronica o avvisi per dispositivi mobili.

  • Quando più connettori sono ospitati in un singolo computer:

    • Il modello di denominazione del contenitore è sapcon-<SID>, quindi non è possibile connettersi a più sistemi con lo stesso SID.
    • Se ci si connette a più sistemi con ID client diversi, usare l'opzione --multi-clients non documentata quando si esegue lo script di kickstart. Il contenitore creato ha il modello sapcon-<SID>-<client>di denominazione .
    • Quando ci si connette a più sistemi con lo stesso SID e lo stesso ID client, il connettore deve essere distribuito in host diversi. I sistemi potrebbero avere numeri di sistema diversi. Il connettore deve essere distribuito anche in host diversi per più ambienti di sistema, ad esempio produzione, sviluppo o test, che usano lo stesso SID, l'ID client o il numero di sistema. I dati di Log Analytics di questi sistemi sono indistinguishable. Quando si utilizzano sistemi con ID sid identici, ID client o numeri di sistema, usare aree di lavoro Log Analytics diverse per distinguere i dati.

Server applicazioni SAP

  • Usare un connettore SAP per connettere i server ABAP a Microsoft Sentinel.
  • Installare il connettore SAP in una macchina virtuale separata.
  • Ogni sistema SAP con un ID di sistema univoco richiede un connettore SAP separato.
  • Archiviare le credenziali in Azure Key Vault.
  • Per eseguire il pull dei dati in ogni sistema SAP, assegnare i ruoli e le autorizzazioni appropriati specifici all'integrazione di Microsoft Sentinel.
  • Nei sistemi SAP monitorati abilitare la registrazione delle modifiche alle tabelle SAP e la registrazione ABAP.
  • Ottimizzare il connettore SAP per evitare dump brevi e eseguire il pull della quantità di dati appropriata.
  • Per eliminare i falsi positivi, implementare un processo iterativo per ottimizzare gli avvisi in Microsoft Sentinel. Ad esempio, consentire agli utenti di selezionare di eseguire query sensibili.

Server di database SAP HANA

  • Microsoft Sentinel si basa sui log inseriti nell'area di lavoro da SAP HANA tramite il protocollo di registrazione del sistema (syslog). In questo scenario non sono presenti connettori SAP.

  • Per eseguire il push del syslog SAP HANA in un'area di lavoro di Microsoft Sentinel, installare l'agente di Monitoraggio di Azure in parallelo alla versione standard di Microsoft Operations Management Suite. Per impostazione predefinita, Operations Management Suite esegue il push dei dati nell'area di lavoro di telemetria. È possibile reindirizzare i log dell'agente di Monitoraggio di Azure all'area di lavoro Microsoft Sentinel.

  • Per impostazione predefinita, il controllo SAP HANA viene scritto in una tabella di database denominata CSTABLE. Il team di sicurezza usa funzionalità, ad esempio l'acquisizione degli account di accesso dei vigili del fuoco, per utilizzare i log di controllo dai database. Non è possibile riconnettere la registrazione predefinita a syslog, ma è possibile reindirizzare percorsi di controllo diversi a destinazioni diverse, in modo che tutti i criteri di controllo correlati a Microsoft Sentinel puntino al livello di avviso. Quando si implementa questa modifica, tutti i log a livello di avviso passano a syslog.

Regole di Microsoft Sentinel

Le regole di Microsoft Sentinel consentono di individuare minacce e comportamenti anomali nell'ambiente. Durante la fase di analisi e progettazione:

  • Esaminare le regole esistenti. Determinare quali regole di analisi predefinite esistono per SAP e Microsoft Sentinel.
  • Stabilire l'ambito. Definire l'ambito e i casi d'uso per la situazione.
  • Stabilire criteri di regola. Stabilire criteri per l'identificazione e la priorità delle regole.
  • Priorità delle regole. Identificare e definire la priorità delle regole per l'implementazione.

Si applicano anche le considerazioni di progettazione seguenti:

  • Per identificare i falsi positivi e modificare la logica di query e le voci watchlist di conseguenza, stabilire un processo per esaminare e convalidare gli avvisi.

  • Usare gli elenchi di controllo per correlare i dati da un'origine dati con gli eventi nell'ambiente Microsoft Sentinel.

    • Ad esempio, è possibile creare un elenco di controllo con un elenco di asset ad alto valore, dipendenti terminati o account di servizio nell'ambiente.
    • Le regole esistenti usano elenchi di controllo statici che contengono un elenco di utenti. È tuttavia possibile configurare le regole per fornire a Microsoft Sentinel un'origine dati dinamica aggiornabile delle risorse valutate da Microsoft Sentinel.
    • Le regole di analisi sfruttano l'elenco di controllo SAP_User_Config. Ad esempio, se un utente genera un numero eccessivo di avvisi, l'utente viene aggiunto all'elenco di controllo con tag, ad MassiveLogonsOK esempio o MassiveRFCOK, per evitare un disturbo.

  • Usare le cartelle di lavoro predefinite per identificare le lacune nei dati e monitorare l'integrità del sistema.

  • Usare regole di esfiltrazione per monitorare la perdita di dati. Per altre informazioni, vedere Regole di esfiltrazione dei dati e Regole di rilevamento dell'esfiltrazione dei dati.

Passaggi successivi