Sie sehen die Flagge von Österreich

BMD
Österreich

Sie sehen die Flagge von Deutschland

BMD
Deutschland

Sie sehen die Flagge der Schweiz

BMD
Schweiz

Sie sehen die Flagge von Ungarn

BMD
Magyarország

Sie sehen die Flagge der Slowakei

BMD
Slovensko

Sie sehen die Flagge von Tschechien

BMD
Česko

Sie sehen die englische Flagge

BMD
International

Sie sehen die Flagge von Österreich AT
Suchen

NTCS Hardening Guide

1. Allgemeines
2. Betriebssysteme
    2.1. Betriebssystem Patches
    2.2. Verwendete SSL-Protokolle
3. SQL-Server
    3.1. SQL CU
    3.2. SQL-Transportverschlüsselung
    3.3. SQL-Account
    3.4. SQL-Datenbankverschlüsselung (TDE)
    3.5. SQL-Backupverschlüsselung
4. NTCS Installation
    4.1. User BMD
    4.2. NTFS-Berechtigungen anpassen
    4.3. BMD Client Service
    4.4. NTCS Login-Verfahren anpassen
        4.4.1. Standardauthentifizierung (verschlüsselt)
        4.4.2. Standardauthentifizierung
        4.4.3. Windowsauthentifizierung
    4.5. BMDNTCS Soap User mit minimalen Rechten
    4.6. BMDNTCSSvc-Konto anpassen
    4.7. DMS-Verzeichnis-Überwachung
5. NTCS Parameteranpassungen
    5.1. Verschlüsselung der Logfiles
    5.2. Verschlüsselung BMDNTCSSvc aktivieren
    5.3. Kennwortrichtlinie aktivieren
    5.4. SMTP-Versand
6. Webserver
    6.1. 2-Faktor-Authentifizierung
    6.2. SSL-Kommunikation Webseite
    6.3. HTTP Response Headers entfernen & setzen
    6.4. AMSI-Schnittstelle für Databox
    6.5. Standardwebseite ändern
    6.6. Speichern der Zugangsdaten verhindern
    6.7. Verhalten der Webapplikation steuern

Detailansicht Technik

1. ALLGEMEINES

Diese Anleitung dient dazu, eine bestehende NTCS Installation möglichst sicher zu gestalten. Dabei werden sowohl Einstellungen seitens des Betriebssystems als auch der NTCS beschrieben bzw. empfohlen.

 

Diese Anleitung richtet sich an versierte Administratoren. Es ist kundenseitig abzuwägen, welche Einstellungen umgesetzt werden können, ohne andere Software, welche ebenfalls im Einsatz ist, negativ zu beeinflussen. Bei dieser Anleitung wird von einem System ausgegangen, bei dem ausschließlich die NTCS Software im Einsatz ist.

 

Bei einigen Maßnahmen ist eine sichere Umgebung vorrangiger als ein bestimmter Komfortgewinn.

Detailansicht Technik

2. BETRIEBSSYSTEME

Grundvoraussetzung ist, dass das aktuellste Microsoft Betriebssystem sowohl am Client als auch am Server verwendet wird, welche laut Systemvorausetzungen freigegeben sind.

Detailansicht Technik

2.1. Betriebssystem Patches

Das Betriebssystem muss sich auf dem aktuellsten Patchstand befinden und nur die unbedingt notwendige Software sollte darauf installiert sein. Im Sinne eines ganzheitlichen Sicherheitskonzeptes muss jegliche zusätzlich installierte Software ebenfalls entsprechend auf dem aktuellen Stand gehalten und bekannte Sicherheitslücken müssen geschlossen werden.

Detailansicht Technik

2.2. Verwendete SSL Protokolle

Es sollten alle derzeit unsicheren Protokolle für die SSL-Verschlüsselung am Server deaktiviert werden. Dies gilt vor allem für SSL 3.0, TLS 1 und TLS 1.1. Zusätzlich sollten die Verschlüsselungsverfahren auf nur als sicher geltende Verfahren eingeschränkt werden.

 

Dazu empfiehlt es sich, entweder über diverse Drittanbietertools die notwendigen Einstellungen vorzunehmen (https://www.nartac.com/Products/IISCrypto) oder alternativ die Settings via GPO oder Registry Werte anzupassen (siehe https://docs.microsoft.com/de-de/troubleshoot/windows-server/windows-security/restrict-cryptographic-algorithms-protocols-schannel).

 

Wird der Server auch als Webserver eingesetzt, so muss bzw. kann die Prüfung der aktiven Protokolle sehr einfach über diverse Webdienste erfolgen (https://www.SSLlabs.com/ssltest/ und securityhandler.com/).

 

Damit auch die NTCS Clients über TLS 1.2 mit dem BMD Server / SQL Server kommunizieren können, muss sichergestellt werden, dass der aktuellste SQL Native Client installiert ist. Diesen können Sie entweder direkt von Microsoft beziehen (siehe KB3135244 - TLS 1.2 support for Microsoft SQL Server - Microsoft Support ) oder Sie finden eine kompatible Version unter \\ihr-bmd-server\bmdntcs_pgm\redist – dort befinden sich die Dateien SQLNCLI11_X64.MSI (für 64-bit Windows) bzw. SQLNCLI11.MSI (für 32-bit Windows).

Detailansicht Technik

3. SQL-SERVER

Detailansicht Technik

3.1. SQL CU

Der SQL-Server muss nach der Installation mit allen relevanten Servicepacks oder Cumulative Updates aktualisiert werden. Auf dem BMD Installationsmedium befindet sich nicht das aktuellste CU von Microsoft.

Auf dieser Seite kann das aktuellste CU heruntergeladen und installiert werden.
https://docs.microsoft.com/en-us/sql/database-engine/install-windows/latest-updates-for-microsoft-sql-server?view=sql-server-ver15

Detailansicht Technik

3.2. SQL-Transportverschlüsselung

Um die Kommunikation zwischen SQL-Server und SQL-Client zu verschlüsseln, ist es notwendig, dies am Server zu aktivieren.

 

Dies ist entsprechend der Microsoft-Anleitung durchzuführen:
https://docs.microsoft.com/de-de/sql/database-engine/configure-windows/enable-encrypted-connections-to-the-database-engine?view=sql-server-ver15 

 

Es ist empfohlen, ein öffentliches Zertifikat zu verwenden oder ein Zertifikat von einer internen CA, welchem alle Rechner vertrauen.

 

Für Testzwecke kann auch ein selbsterstelltes Zertifikat verwendet werden.

Detailansicht Technik

3.3. SQL-Account

Das NTCS Setup installiert die SQL-Dienste unter dem Account „Local System“. Da dieser Account sehr weitrechende Rechte am System hat, sollte ein eigenes SQL-Dienstekonto verwendet werden.
Sowohl das Dienstekonto des SQL-Servers (MSSQL$BMD) als auch des SQL-Agents (SQLAgent$BMD) sollten entsprechend angepasst werden.

 

Eine Anleitung ist hier zu finden:
https://docs.microsoft.com/en-us/sql/database-engine/configure-windows/scm-services-change-the-service-startup-account?view=sql-server-ver15 

 

Idealerweise sollte für die beiden Konten nach Möglichkeit ein Managed Service Account verwendet werden. Dies hat den Vorteil, dass das Kennwort des Kontos vom Betriebssystem in regelmäßigen Abständen selbstständig verändert wird. Somit ist ein zusätzlicher Sicherheitsgewinn gegeben.

 

Unter folgendem Link ist eine entsprechende Anleitung zu finden:
https://docs.microsoft.com/en-us/sql/database-engine/configure-windows/configure-windows-service-accounts-and-permissions?view=sql-server-ver15 

Detailansicht Technik

3.4. SQL-Datenbankverschlüsselung (TDE)

Um die komplette Datenbank zu verschlüsseln, kann die sogenannte „Transparent Data Encryption“ verwendet werden. Diese ermöglicht es, dass alle Inhalte der Daten automatisch verschlüsselt werden.
Dieses Feature erfordert bis zur SQL-Serverversion 2017 die Enterprise Edition. Ab der SQL-Serverversion 2019 ist dies nun auch in der Standard Edition vorhanden.

 

Unter folgendem Link ist die entsprechende Anleitung zur Aktivierung zu finden:
https://docs.microsoft.com/en-us/sql/relational-databases/security/encryption/transparent-data-encryption?view=sql-server-ver15 

Detailansicht Technik

3.5. SQL-Backupverschlüsselung

Das SQL-Backup sollte auf jeden Fall verschlüsselt gespeichert werden. Dazu muss der entsprechende SQL-Backupjob angepasst werden, sodass die Verschlüsselung beim Erstellen des Backups durchgeführt wird.

 

Dazu sind folgende zusätzliche Schritte notwendig:
https://docs.microsoft.com/en-us/sql/relational-databases/backup-restore/create-an-encrypted-backup?view=sql-server-ver15 

 

Im Anschluss empfiehlt es sich, das SQL-Backup nach den BMD Vorgaben einzurichten (siehe https://www.bmd.com/technische-dokumentation/einrichten-einer-sql-sicherung-fuer-bmd-ntcs.html) und dann die vorgegebenen Backup-Jobs um die Verschlüsselung zu erweitern.

Bitte beachten Sie aber, dass bei einem verschlüsselten Backup-File kein "Anhängen" (appending) möglich ist. Daher kann das Translog-Backup nicht in dasselbe Backup-File erfolgen wie das Full-Backup. Somit muss entweder pro Translog-Backup-Job ein eigenes Backup-File verwendet werden (und dieses täglich überschrieben werden) oder es wird alternatic ein Diff-Backup-Job eingerichtet, welcher jeweils um 9, 12, 15, oder 18 Uhr läuft und das bestehende Diff-Backup-File überschreibt.

Hintergrund: https://docs.microsoft.com/en-us/sql/relational-databases/backup-restore/backup-encryption?view=sql-server-ver15#Restrictions

Detailansicht Technik

4. NTCS INSTALLATION

Detailansicht Technik

4.1. User BMD

Der Benutzer BMD wird automatisch durch das Setup der Datenbank angelegt und kann mit dem Konto „Administrator“ in Windows verglichen werden. Bereits bei der Installation sollte ein sehr komplexes Kennwort festgelegt werden und dieser Benutzer ist nicht für den laufenden Betrieb gedacht. Jeder NTCS Benutzer muss über einen eigenen Datenbank-User verfügen, ansonsten können Änderungen in der Datenbank nicht richtig nachvollzogen werden, wenn nicht jeder Benutzer auf eine natürliche Person schließen lässt.

 

Für administrative Aufgaben in der NTCS ist empfohlen, einen getrennten Admin-Account zu verwenden. So kann sauber zwischen täglichen Arbeiten und administrativen Tätigkeiten (Anpassungen Berechtigungen, Anpassung globaler Parameter usw.) unterschieden werden. Das hat auch den Vorteil, dass Berechtigungsanpassungen mit dem „normalen“ Account getestet werden können.

Detailansicht Technik

4.2. NTFS-Berechtigungen anpassen

Durch die NTCS Installation werden zwei Freigaben angelegt. BMDNTCS_PGM und BMDNTCS_PGMDATA. Für diese Freigaben gibt es keine Einschränkungen, was den Zugriff betrifft. Daher sollten folgende Anpassungen nach der Installation vorgenommen werden:

 

BMDNTCS_PGMDATA
In dieser Freigabe befinden sich alle Verzeichnisse, auf der die Benutzer, welche mit der NTCS Software arbeiten, Schreibrechte benötigen. Dort werden u. a. Logdateien erzeugt oder auch temporäre Dateien geschrieben. Auch werden dort exportierte Daten abgelegt und ähnliches.

 

Es empfiehlt sich daher, eine eigene Gruppe anzulegen (z. B. Gruppe-NTCS-Benutzer). In diese Gruppe sind alle Windows-Accounts der Benutzer aufzunehmen, welche die NTCS Software verwenden. Die NTFS-Berechtigungen (und auch die Freigabe-Rechte) sind dann so anzupassen, dass nur mehr diese Gruppe Schreibrechte auf das Verzeichnis hat.

 

BMDNTCS_PGM
In dieser Freigabe befinden sich alle notwendigen Daten, welche der NTCS Client benötigt um lauffähig zu sein. Dort befinden sich u. a. diverse globale Konfigurationsdateien. Auf dieses Verzeichnis benötigen die NTCS Benutzer grundsätzlich nur Leserechte. Schreiberechte sind ausschließlich nur dann nptwendig, um NTCS Updates oder NTCS Patches zu installieren oder um administrative Tätigkeiten durchzuführen.

 

Dazu zählen unter anderem die Anpassung der BMD.INI oder BMDGLOBAL.INI-Datei. Dort werden z. B. SQL-Aliasnamen verwaltet, globale Einstellungen für das BMD Call Center usw.

 

Es empfiehlt sich daher, die oben genannte „Gruppe-NTCS-Benutzer“ mit Leserechten zu beschränken (sowohl NTFS- als auch Freigabe-Berechtigung).

 

Zusätzlich sollte eine eigene Gruppe angelegt werden (z. B Gruppe-NTCS-Admin-Benutzer). In dieser Gruppe sind alle Windows-Accounts der Benutzer aufzunehmen, welche oben genannte administrative Tätigkeiten in der NTCS Software durchführen. Die NTFS-Berechtigungen (und auch die Freigabe-Rechte) sind dann so anzupassen, dass nur mehr diese Gruppe Schreibrechte auf das Verzeichnis hat.

Detailansicht Technik

4.3. BMD Client Service

Die NTCS Software installiert auf allen Clients und auch am Server einen eigenen Dienst namens „BMD Client Service“. Dieser Service ist notwendig, damit jeder Benutzer auf seiner Workstation auch ohne administrative Rechte eine vollständige Aktualisierung des NTCS Clients durchführen kann.

 

Folgender Ablauf findet dabei statt:
Ein Benutzer meldet sich auf seiner Workstation an. Dabei wird automatisch die Datei C:\Program Files(x86)\BMDNTCS\BMDNTCSClients\“Servername“\BMDNetclient.exe gestartet. Diese vergleicht den lokal installierten Programmstand mit der Serverversion. Werden Unterschiede gefunden, so versucht die BMDNetClient.exe den lokalen Programmstand zu aktualisieren. Dabei kann es u. a. auch notwendig sein, z. B. neue Komponenten (.Net Version, SQL Native Client) zu installieren oder bestimmte DLLs zu registrieren. Reichen die Rechte des angemeldeten Benutzers dazu nicht aus, so wird diese Aufgabe dem „BMD Client Service“ übergeben. Da dieser unter „Local System“ läuft, können derartige Änderungen am System durchgeführt werden.

Detailansicht Technik

4.4. NTCS Login-Verfahren anpassen

In der Standardinstallation vor der NTCS-Version 2021.24.01 verwendet die NTCS Software ein Login-System mit einem gemeinsamen SQL-User (BMDSA) – die Verwaltung der Benutzerrechte innerhalb der NTCS Software wird über ein eigenes Berechtigungskonzept geregelt. Da der BMDSA-Benutzer sowohl das Recht für die Verbindung zum SQL-Server als auch DBOwner Rechte auf die BMD Datenbank hat, kann dies ein Sicherheitsrisiko darstellen. Bitte beachten Sie, dass dieses Login-System bei einer Neuinstallation seit der NTCS-Version 2021.24.01 nicht mehr zum Einsatz kommt.

Detailansicht Technik

4.4.1 Standardauthentifizierung (verschlüsselt)

Es besteht die Möglichkeit, wenn Sie noch das alte Login-System verwenden, das NTCS Login-System umzustellen. Direkt am Server BMDDBUpdate.exe starten. Dort mit dem BMD Benutzer einsteigen und unter Extras → Diverse Serviceroutinen → „Umstellung des Authentifizierungsverfahrens“ auswählen. Im neuen Fenster muss dann „Standardauthentifizierung (verschlüsselt)“ gewählt und mit „Übernehmen“ die Aktivierung bestätigt werden.

 

Für den Zugriff kommt dabei der SQL Native Client zum Einsatz. Bitte beachten Sie, dass die Verschlüsselung zwischen Client und SQL-Server zusätzlich (siehe Punkt 3.2.) konfiguriert werden muss.

 

Um dieses neue Login-System zu verwenden, sind folgende Anpassungen durchzuführen:
Direkt am Server BMDDBUpdate.exe starten. Dort mit dem BMD-Benutzer einsteigen und unter „Extras“ – „Diverse Serviceroutinen“ – „Umstellung des Authentifizierungsverfahren“ auswählen. Im neuen Fenster muss dann mit „Übernehmen“ die Aktivierung bestätigt werden.

Dadurch wird am SQL-Server ein neuer Account angelegt (BMD_%RandomID%) und entsprechend berechtigt und in der BMD.INI in der Sektion [BMD\ALIASCONFIG] der Wert SQLSERVER\INSTANZ:DATENBANK=ENCRYPTED eingetragen.

 

Zusätzlich sollte noch in der Datei BMD.INI in der Sektion [BMD] ein Eintrag SQLCLIENT=DIRECT erstellt werden. Damit kommt ein proprietäres Zugriffsverfahren zum Einsatz (welches den SQL Native Client bzw. den OLE-DB-Treiber ersetzt). 

 

In den Systeminformationen (? > Info > Systeminformationen) können Sie unter dem Punkt „Datenbank“ den Zugriffsmodus kontrollieren. Es muss dann „Configured: DIRECT“ vorhanden sein.

 

Diese Kombination gilt auch als die bevorzugte Variante für den Zugriff auf den SQL-Server und sollte in Umgebungen mit hohen Sicherheitsanforderungen eingesetzt werden.

 

Der bestehende Benutzer BMDSA sollte nun deaktiviert werden. Nach einem erfolgreichen Testeinstieg in die NTCS Software sollte dieser dann endgültig gelöscht werden.

Detailansicht Technik

4.4.2.    Standardauthentifizierung

Es besteht auch die Möglichkeit, dass mit zwei SQL-Accounts gearbeitet wird. Dabei wird die Verbindung zum SQL-Server mit einem Account vorgenommen, anschließend wird mit dem zweiten Account eine Verbindung zur Datenbank aufgebaut. Jeder der beiden Accounts hat nur die jeweilige Berechtigung – somit wird einem Missbrauch vorgebeugt (Stichwort SQL Application Role).

 

Für den Zugriff kommt dabei der SQL Native Client bzw. MSOLEDB zum Einsatz. Bitte beachten Sie, dass die Verschlüsselung zwischen Client und SQL-Server zusätzlich (siehe Punkt 3.2.) konfiguriert werden muss.

 

Um dieses Login-System zu verwenden, sind folgende Anpassungen durchzuführen:
Direkt am Server BMDDBUpdate.exe starten. Dort mit dem BMD Benutzer einsteigen und unter Extras → Diverse Serviceroutinen → „Umstellung des Authentifizierungsverfahrens“ auswählen. Im neuen Fenster muss dann mit „Übernehmen“ die Aktivierung bestätigt werden.

 

NTCS Hardening Guide: Umstellung NTCS-Anmeldung

Dabei werden am SQL-Server zwei neue Accounts angelegt und entsprechend berechtigt. Zusätzlich wird in der BMD.INI in der Sektion [BMD\ALIASCONFIG] der Wert „SQLSERVER\INSTANZ:DATENBANK“=EXTENDED eingetragen.

 

Im SQL Management Studio sind die neuen Accounts ersichtlich – diese werden mit einer zufällig erzeugten SID angelegt.

 

NTCS Hardening Guide: SQL-Logins

Der bestehende Benutzer BMDSA sollte nun deaktiviert werden. Nach einem erfolgreichen Testeinstieg in die NTCS Software sollte dieser dann endgültig gelöscht werden.

 

Dieses Login-System gilt aber als abgekündigt und wird in absehbarer Zeit nicht mehr unterstützt.

Detailansicht Technik

4.4.3.    Windowsauthentifizierung

Für Spezialfälle besteht noch die Möglichkeit, dieses Login-System einzusetzen.
Direkt am Server BMDDBUpdate.exe starten. Dort mit dem BMD-Benutzer einsteigen und unter Extras → Diverse Serviceroutinen → „Umstellung des Authentifizierungsverfahrens“ auswählen. Im neuen Fenster sind dann folgende Schritte vorzunehmen: „Windowsauthentifzierung“ wählen, eine bereits vorhandene Windows-Gruppe eingeben und mit „Übernehmen“ die Aktivierung bestätigen. Für den Zugriff auf den SQL-Server kommt der SQL Native Client zum Einsatz. 
Dabei werden am SQL-Server dieser Windows-Gruppe DBOwner-Rechte auf die Datenbank gegeben. Zusätzlich wird in der BMD.INI in der Sektion [BMD\ALIASCONFIG] der Wert „SQLSERVER\INSTANZ:DATENBANK“=WINDOWS eingetragen.

 

Jeder Benutzer greift somit mit seinem Windows-Account direkt auf den SQL-Server zu.
Bitte beachten Sie dass in dieser Konfiguration die Benutzer auch direkt mittels SQL Management Studio oder ähnlichen Werkzeugen zugreifen können.

 

Für alle Verfahren gilt:
Sind Webapplikationen auf einem getrennten Webserver im Einsatz, so wird das neue Authentifizierungsverfahren gegebenenfalls vom BMDNTCS Update-Dienst auch dort aktiviert. Ansonsten muss direkt im Verzeichnis der jeweiligen Webapplikation in der BMD.INI der entsprechende [BMD\ALIASCONFIG] Eintrag gesetzt werden.

 

Zusätzlich muss für die verschlüsselte Kommunikation (unabhängig vom Login-Verfahren) am SQL-Server die Transportverschlüsselung aktiv sein (siehe Punkt 3.2.).

Detailansicht Technik

4.5.    BMD NTCS Soap User mit minimalen Rechten

Um die NTCS Stapelverarbeitung nutzen zu können, muss ein passender Betriebssystembenutzer hinterlegt werden, mit dem direkt am Server die Aufgabenplanung angesprochen wird und die NTCS Prozesse gestartet werden. Um eine möglichst sichere Umgebung zu gewährleisten, sollte dieser Benutzer nur die minimal erforderlichen Rechte haben und es sollte dazu kein administrativer Account verwendet werden.

 

Zusätzlich sollte der BMDNTCSSOAPSvc am Server von Account „Local System“ auf einen eigenen Windows-Account umgestellt werden.

 

Folgende Betriebssystemrechte sind notwendig:

  • das Recht „Anmelden als Stapelverarbeitungsauftrag“
  • das Recht „Anmelden als Dienst“ 

Zusätzlich noch:

  • Zugriffsrechte auf die BMD NTCS Verzeichnisse (NTFS + Share)
    • Lesen auf C:\Program Files\BMDSoftware und auch BMDNTCS_PGM 
    • Ändern auf C:\Users\Public\Documents\BMDSOFTWARE\BMDNTCS und auch BMDNTCS_PGMDATA
  • Ändern auf %WinDir%\Temp 
  • Ändern auf %Temp% 
  • Ändern auf jene Verzeichnisse/Dateien, auf welche der jeweilige Stapel zugreift

Detailansicht Technik

4.6. BMDNTCSSvc Konto anpassen

Das NTCS Setup installiert den BMDNTCSSvc-Dienst standardmäßig unter "Local System". Dieser Dienst ist u. a. dafür zuständig, Archivdokumente zu speichern bzw. im Dateisystem abzurufen oder wird auch als Updateservice für die Webapplikation verwendet.

 

Da der "Local System Account" sehr weitreichende Rechte im System hat, wird empfohlen, den Dienst unter einem eingeschränkten Konto laufen zu lassen.

 

Folgende Betriebssystemrechte sind notwendig:

  • das Recht „Anmelden als Dienst“ 


Zusätzlich noch:

  • Zugriffsrechte auf die BMD NTCS Verzeichnisse (NTFS + Share)
    • Ändern auf - C:\Program Files\BMDSoftware und auch BMDNTCS_PGM 
    • Ändern auf C:\Users\Public\Documents\BMDSOFTWARE\BMDNTCS und auch BMDNTCS_PGMDATA
  • Ändern auf %WinDir%\Temp 
  •  Ändern auf %Temp% 
  • Ändern auf alle hinterlegten DMS-Pfade (DMS - Pfade)
    • Dabei ist darauf zu achten, dass auf alle hinterlegten Pfade Änderungsrechte notwendig sind:

Detailansicht Technik

4.7. DMS-Verzeichnis-Überwachung

Das NTCS Archiv erkennt grundsätzlich jede Manipulation an archivierten Dokumenten. Allerdings kann es schwierig sein, festzustellen wodurch eine Veränderung der Dateien passiert ist. So kann eine Manipulation auch außerhalb der NTCS Software durchgeführt werden (Administrator direkt am DMS-Server).
Um solchen Zugriff zu überwachen, sind seitens des Betriebssystems die entsprechenden Protokolle zu aktivieren und diese sind auch zu schützen.

 

Dazu ist es notwendig, folgende Überwachung zu aktivieren auf den zu überwachenden Ordnern.

 

NTCS Hardening Guide: Überwachung

Folgende Überwachungseinträge müssen aktiviert werden:
 

File/Folder ChangesEveryoneSuccess and FailureCreate Files/Write Data
Create Folders/Append Data
Write Attributes
Write Extended Attributes
Delete Subfolders and Files
Delete
This Folder, Subfolder and Files
Folder Permissions and Owner ChangesEveryoneSuccess and FailureTake Ownership
Change Permissions
This Folder, Subfolder and Files
File ReadEveryoneSuccess and FailureList Folder/Read DataFiles only
Folder Read FailureEveryoneFailureList Folder/Read DataThis Folder and Subfolder


Damit wird sichergestellt, dass im Eventlog des DMS-Servers die Änderungen im Dateisystem entsprechend protokolliert werden

 

Es wird auch empfohlen, eine Software einzusetzen, welche diese Veränderungen in einer externen Datenbank speichert. Der Eventlog des DMS-Servers wird regelmäßig überschrieben bzw. kann auch der Administrator diesen absichtlich löschen. Ein solches Tool bietet zum Beispiel der Hersteller Manage Engine mit dem Tool ADAuditPlus (https://www.manageengine.com/products/active-directory-audit/). Dieses überwacht die entsprechenden Verzeichniszugriffe und speichert die Änderungen in einer separaten Datenbank. Auf diese Datenbank darf dann der DMS-Administrator natürlich keinen Zugriff haben.
 

Detailansicht Technik

5. NTCS PARAMETERANPASSUNGEN

Detailansicht Technik

5.1. Verschlüsselung der Logfiles

Viele Logfiles der NTCS werden in der Serverfreigabe BMDNTCS_PGMDATA im Unterverzeichnis LOG gespeichert. Aus diesen Logfiles können u. a. sensible Informationen gelesen werden. Daher wird empfohlen, die Logfiles verschlüsselt zu speichern. Dies hat den Vorteil, dass die Logfiles nur mehr mit dem NTCS Log Viewer (TOOLS ➡ Tools ➡ Protokolle ➡ Logdateien) angesehen werden können. Der Aufruf des Log Viewers muss im NTCS Berechtigungssystem entsprechend eingeschränkt werden.

 

Die Verschlüsselung der Logfiles muss über folgenden Parameter aktiviert werden:

 

TOOLS ➡ Tools ➡ Einstellungen ➡ TOOLS Parameter ➡ Berechtigung ➡ Allgemeine Einstellungen ➡ Berechtigung ➡ Log-Dateien verschlüsseln ➡ Ja

NTCS Hardening Guide: Log Datei verschlüsseln

Zusätzlich muss noch unter „Passwort für Log-Dateien“ ein Kennwort vergeben werden. Dieses ist notwendig, wenn z. B. auf einem anderen System die Log-Dateien gelesen werden müssen. Muss der BMD Support beispielsweise solche Logfiles analysieren, so benötigt dieser das entsprechende Kennwort.

 

Sobald die NTCS nun neu gestartet wird, können die Logfiles nicht mehr im Klartext gelesen werden.

Detailansicht Technik

5.2. Verschlüsselung BMDNTCSSvc aktivieren

Um zum Beispiel Archivdokumente vom NTCS Archiv zum Client zu übertragen, wird der BMDNTCSSvc verwendet. Der NTCS Client baut eine TCP-Verbindung zu dem Dienst am Server auf und diese überträgt dann die notwendigen Dateien (oder speichert diese im Archiv am Server).

 

Um die verschlüsselte Übertragung dieser Kommunikation zu aktivieren, ist wie folgt vorzugehen:
TOOLS ➡ Tools ➡ Einstellungen ➡ TOOLS Parameter ➡ Gesamtsystem ➡ BMD NTCS-Service ➡ Sicheren Zugriff verwenden ➡ 3 - TLS Version 1.2

NTCS Hardening Guide

Unter dem Punkt „Serverzertifikat“ kann im Bedarfsfall noch die Schlüssellänge erhöht werden. Das Zertifikat wird beim nächsten Neustart des BMDNTCSSvc-Dienstes erzeugt und von den Clients dann verwendet.

Detailansicht Technik

5.3. Kennwortrichtlinie aktivieren

Bei NTCS Installationen, welche schon länger im Einsatz sind, ist möglicherweise die Kennwortrichtlinie noch nicht aktiviert. Diese sollte unbedingt aktiviert werden, um sicherzustellen, dass alle NTCS Benutzer zum einen ihre Kennwörter regelmäßig ändern und dabei die vorgegebene Komplexität einhalten.

 

Zur Aktivierung ist wie folgt vorzugehen:

Unter TOOLS → Tools → Einstellungen → TOOLS Parameter → Berechtigungen → Allgemeine Einstellungen → Kennwort muss der Parameter „Überprüfung der Kennwortrichtlinie“ auf 1 oder 2 gesetzt sein

 

NTCS Hardening Guide: Kennwortrichtlinie

Zusätzlich können die gewünschten Parameter für die Kennwortrichtlinie angepasst werden.

Detailansicht Technik

5.4. SMTP-Versand 

Die NTCS Software bietet verschiedene Möglichkeiten, wie Mails erzeugt bzw. versendet werden können. Bei den verschiedenen Varianten ist immer zwischen Sicherheit und Komfort abzuwägen. Um ein möglichst sicheres System zu betreiben, bei dem es nicht notwendig ist, die SMTP-Zugangsdaten innerhalb der NTCS zu speichern, ist folgender Parameter zu aktivieren:

 

TOOLS ➡ Tools ➡ Einstellungen ➡ TOOLS Parameter ➡ Gesamtsystem ➡ Allgemeine Einstellungen ➡ Standard-E-Mail ➡ SMTP-Mail Versandsystem

 

Dort ist der Parameter auf „2 - Direkt über Mailserver mit DefaultNetworkCredentials“ zu setzen.
 

NTCS Hardening Guide: SMTP Globel

Dies setzt voraus, dass der eingesetzte Mailserver den lokal angemeldeten Windows-User erkennt und automatisch authentifizieren kann. Dies ist beispielsweise bei einem Microsoft Exchange Server der Fall.

 

Zusätzlich muss noch der SMTP-Server im Parameter global hinterlegt werden. Ebenso ist der entsprechende Port zu definieren. Der Parameter „TLS für SMTP aktivieren“ ist auf "3 – TLS Version 1.2" zu setzen. Der SMTP-Server muss dies natürlich unterstützen.

 

Sobald diese globalen Daten hinterlegt sind, können die Benutzer direkt via SMTP aus der NTCS Mails versenden. Dabei wird die bei ihnen hinterlegte Mailadresse aus den Mitarbeiterstammdaten verwendet. Für diese Mailadresse muss der jeweilige Windows-Benutzer, mit dem die NTCS gestartet worden ist, auch am Mailsystem berechtigt sein. Vorteil dieser Konfiguration ist, wie schon erwähnt, dass keinerlei SMTP-Zugangsdaten innerhalb der NTCS gespeichert werden müssen.

 

Nachteil ist aber natürlich, dass ein asynchroner Mailversand in dieser Konstellation nicht möglich ist. Beim asynchronen Mailversand übernimmt der BMDNTCSSoapService den Versand der Mails via SMTP. Dabei werden diese vorab in der Datenbank gespeichert und dann erst übertragen. Somit ist es nicht notwendig, dass die NTCS Applikation den Versand von jeder Mail abwarten muss (z. B. Standardbrief). Dazu müssen die SMTP Daten allerdings in der Datenbank gespeichert werden. 

 

Eine detaillierte Erklärung zu den verschiedenen SMTP Einstellungen finden Sie in der Onlinehilfe unter:
https://www.bmd.at/Portaldata/1/Resources/help/00.00/OES/Documents/1372702529000101160.html

Detailansicht Technik

6. WEBSERVER

Detailansicht Technik

6.1. 2-Faktor-Authentifizierung

Da beim Einsatz der BMD Web- und BMD Com Applikationen natürlich zwangsweise ein Zugriff aus dem Internet stattfindet, wird empfohlen alle NTCS Benutzer-Accounts, welche die Webportale benutzen dürfen, mit der 2-Faktor-Authentifizierung auszustatten.

 

Details zur Einrichtung können der NTCS Onlinehilfe entnommen werden:
https://www.bmd.at/Portaldata/1/Resources/help/00.00/OES/Documents/1372780407000202280.html

 

Zusätzlich muss auch der Parameter kontrolliert werden, um sicherzustellen, dass bei fehlerhaften Anmeldeversuchen das entsprechende Benutzerkonto auch gesperrt wird. Dieser Parameter ist unter TOOLS ➡ Tools ➡ Einstellungen ➡ TOOLS Parameter ➡ Berechtigung ➡ Allgemeine Einstellung ➡ Anmeldung zu finden.

Hier muss der Parameter „Fehlanmeldesperre nach n Versuchen“ auf den gewünschten Wert gesetzt werden (Empfehlung <= 5).

NTCS Hardening Guide: Fehlversuche

Detailansicht Technik

6.2. SSL-Kommunikation Webseite

Grundvoraussetzung ist, dass der Webserver auf einem eigenen Server in einer abgeschotteten DMZ betrieben wird (siehe https://www.bmd.com/fileadmin/user_upload/bmd-com-technischer-aufbau.pdf).

 

Es wird nicht empfohlen, die Webseite für die BMD Web-Applikationen direkt auf dem BMD Server zu betreiben.

 

Die Webseite bzw. der Webserver, auf der/dem die BMD Web-Applikationen laufen, darf nur via SSL erreichbar gemacht werden.

 

Dazu ist systemseitig ein entsprechendes Zertifikat am Webserver zu hinterlegen. Es wird dringend empfohlen, ein öffentliches Zertifikat zu verwenden und die Webseite sowohl intern als auch extern unter dem gleichen DNS-Namen ansprechbar zu machen.

 

Für Testzwecke kann auch ein selbst ausgestelltes Zertifikat verwendet werden.
https://www.bmd.com/technische-dokumentation/erstellen-eines-selbstsignierten-zertifikats.html 
Zusätzlich sind alle als nicht sicher geltenden SSL-Protokolle und Verschlüsselungsverfahren zu deaktivieren (siehe 2.2 – SSL-Protokolle).

 

Zusätzlich sollte am Webserver die „Strict-Transport-Security“ aktiviert werden, um dem Client mitzuteilen, dass die Webseite ausschließlich via HTTPS angesprochen werden darf.
 

NTCS Hardening Guide

Ab Windows Server 2019 kann dies alternativ auch etwas komfortabler über die GUI des IIS-Managers konfiguriert werden.

 

Die Webseite sollte nach der Konfiguration unbedingt einem SSL-Test unterzogen werden, um sicherzustellen, dass die Konfiguration richtig durchgeführt worden ist. Dies kann via ssllabs.com erfolgen – dort sollte die Note A erreicht werden.

Detailansicht Technik

6.3. HTTP Response Headers entfernen & setzen

Um bei externem Zugriff nicht unnötige Informationen preiszugeben, sollten die entsprechenden Response Header entfernt werden. Damit kann z. B. nicht sofort ausgelesen werden, um welchen Webserver es sich handelt, oder ob .Net verwendet wird.

 

Um dies umzusetzen, gibt es mehrere Möglichkeiten. Diese sind hier beschrieben:
https://techcommunity.microsoft.com/t5/iis-support-blog/remove-unwanted-http-response-headers/ba-p/369710 

 

Wir empfehlen dies via „URL Rewrite“ (https://www.iis.net/downloads/microsoft/url-rewrite).

Darüber müssen dann die entsprechenden Outbound Rules angelegt werden. Zusätzlich sollte hier auch der nicht im Artikel angeführte Header „RESPONSE_X-ASPNETMVC-VERSION“ ergänzt werden.

 

Zusätzlich sollten noch folgende HTTP Response Header gesetzt werden:

  • „X-XSS-Protection“ mit dem Wert „1;mode=block“, um „reflected cross-site scripting“ zu verhindern.
  • „X-Content-Type-Options“ mit dem Wert „nosniff“, um „MIME type sniffing“ zu verhindern.
  • „X-Frame-Options“ mit dem Wert „SAMEORIGIN“, um „clickjacking“ zu verhindern.

Dadurch kann die Webapplikation allerdings auch nicht mehr auf einer anderen Webseite als X-Frame eingebunden werden.

Mit dem folgenden Header kann noch verhindert werden, dass nicht explizit freigegebene URLs oder Scripts vom Webserver aufgerufen werden. 
Dazu ist es notwendig, einen Header „Content-Security-Policy“ zu setzen mit folgendem Inhalt:

 

default-src 'self' 'unsafe-inline' http://my.site.com https://my.site.com https://localhost:3719 https://externalsignature.moxis.cloud/ https://*.dynatrace.com data: ;script-src 'self' 'unsafe-eval' 'unsafe-inline' https://*.dynatrace.com blob: http://my.site.com http://my.site.com https://localhost:3719 https://externalsignature.moxis.cloud;img-src 'self' 'unsafe-inline' data:

 

Achtung: Es muss „my.site.com“ in dem Fall durch die tatsächliche URL der Webapplikation ersetzt werden.

 

Detailansicht Technik

6.4. AMSI-Schnittstelle für Databox

Um alle Dokumente, die in die BMD Com Databox, Online Bewerbung, in BMDWeb usw. hochgeladen werden, auf Schadsoftware zu prüfen, wird am Webserver die AMSI-Schnittstelle (Antimalware Scan Interface) von Microsoft verwendet.

 

Daher muss am Webserver ein Virenscanner im Einsatz sein, welcher auch die AMSI-Schnittstelle unterstützt. Dies muss mit dem jeweiligen Hersteller abgeklärt werden.
Der Microsoft Windows Defender unterstützt diese Schnittstelle auf jeden Fall und kann ebenfalls eingesetzt werden.

 

Bitte beachten Sie aber in diesem Fall, dass dieser per Default den Webserver Prozess (w3wp.exe) in den integrierten Ausnahmen enthalten hat. Daher ist es im Falle des Windows Defender auch notwendig, diese Ausnahmen zu deaktivieren.

 

Die notwendigen Schritte sind hier beschrieben:
https://docs.microsoft.com/en-us/windows/security/threat-protection/microsoft-defender-antivirus/configure-server-exclusions-microsoft-defender-antivirus#opt-out-of-automatic-exclusions

 

Achtung!
Es muss die Funktionalität auf jeden Fall geprüft werden. Dazu kann beispielsweise in die Databox eine Eicar-Testdatei hochgeladen werden – diese muss dann entsprechend erkannt werden.

Prüfung der Funktionalität [Screenshot © BMD]

Analog dazu muss auch der entsprechende Virenscanner einen Alarm bzw. Log-Eintrag erzeugen. Im Falle des Windows Defender ist dies im Eventlog des Webservers ersichtlich:

Eventlog des Webservers [Screenshot © BMD]

Detailansicht Technik

6.5. Standardwebseite ändern

Wird am Webserver nur eine BMD Applikation eingesetzt, so empfiehlt es sich, die IIS-Default-Webseite zu ändern. Somit wird vermieden, dass beim Aufruf der Basis-URL ersichtlich ist, dass es sich um einen „Internet Information Server“ handelt. 

 

Dazu muss auf der Default-Website im IIS ein http-Redirect hinterlegt werden auf die gewünschte Webapplikation.

 

Somit landet man beim Aufruf von myurl.mydomain.com automatisch auf myurl.mydomain.com/bmdweb.

Detailansicht Technik

6.6. Speichern der Zugangsdaten verhindern

Es kann in der jeweiligen BMD.INI direkt am Webserver im entsprechenden Verzeichnis der BMD Webapplikation folgender Eintrag gesetzt werden

 

[BMD\BMDCOM2] bzw. [BMD\BMDWEB2]
HIDEPERSISTENTLOGIN=1

 

Dieser Schalter blendet die Option „Angemeldet bleiben“ vom Login-Dialog aus. Zudem wird auch Autocomplete=off bei User-/Passwort-Feldern gesetzt. Dadurch wird auch das Speichern der Zugangsdaten im Browser deaktiviert (zumindest wird der Browser dazu angehalten).

Detailansicht Technik

6.7.    Verhalten der Webapplikation steuern

Da die BMD Webapplikationen grundsätzlich für unterschiedliche Zwecke angesprochen werden können (REST-Schnittstelle, Windows Authentication usw.) ist es auch möglich, ein bestimmtes Verhalten zu erzwingen. Das ist dann sinnvoll, wenn man zum Beispiel verhindern möchte, dass die Webapplikation auch auf REST-Anfragen reagiert.

 

In der BMD.INI der Webapplikation kann folgender Parameter gesetzt werden:

[BMD\BMDWEB2]
HANDLEDREQUESTS=SSO

 

Mit diesem Parameter wird sichergestellt, dass die Webapplikation keine normalen Logins mehr erlaubt. Soll auch die App BMD Go über die gleiche Webseite laufen, so muss der Parameter wie folgt gesetzt werden:

[BMD\BMDWEB2]
HANDLEDREQUESTS=SSO,REST
 

Bereich:

Installationsanleitung NTCS/BMD55/Allgemein


Autor:

BMD-Technik



Betriebliche GesundheitsförderungBMD ist Partner von "Familie und Beruf"Sicherheitszertifikat ISO 27001Das Bild zeigt die Top Arbeitgeber Grafik vom Trend [Grafik © trend]New Work 2021Trusted Cloud

BMD SYSTEMHAUS GesmbH

Sierninger Straße 190

A-4400 Steyr

+43 50 883 oder 0043 7252 883

bmd@bmd.at

Follow us

Folgen Sie uns auf Facebook
Folgen Sie uns auf Xing
Folgen Sie uns auf LinkedIn
Folgen Sie uns auf YouTube
Folgen Sie uns auf Kununu
Folgen Sie uns auf Instagram