NTCS Hardening Guide
https://www.bmd.com/at/technische-dokumentation/ntcs-hardening-guide.html#cap63
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
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.
2. BETRIEBSSYSTEME
Grundvoraussetzung ist, dass das aktuellste Microsoft Betriebssystem sowohl am Client als auch am Server verwendet wird, welche laut Systemvorausetzungen freigegeben sind.
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.
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).
3. SQL-SERVER
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
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.
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
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
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.
4. NTCS INSTALLATION
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.
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.
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.
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.
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.
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.
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.
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.
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.).
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
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:
- Dabei ist darauf zu achten, dass auf alle hinterlegten Pfade Änderungsrechte notwendig sind:
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.
Folgende Überwachungseinträge müssen aktiviert werden:
| File/Folder Changes | Everyone | Success and Failure | Create 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 Changes | Everyone | Success and Failure | Take Ownership Change Permissions |
This Folder, Subfolder and Files |
| File Read | Everyone | Success and Failure | List Folder/Read Data | Files only |
| Folder Read Failure | Everyone | Failure | List Folder/Read Data | This 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.
5. NTCS PARAMETERANPASSUNGEN
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
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.
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
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.
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
Zusätzlich können die gewünschten Parameter für die Kennwortrichtlinie angepasst werden.
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.
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
6. WEBSERVER
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).
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.
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.
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.
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]](https://www.bmd.com/fileadmin/_processed_/5/4/csm_eicar-testdatei_7cddaf758b.jpg "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]](https://www.bmd.com/fileadmin/_processed_/2/6/csm_eventlog_7238df244b.jpg "Eventlog des Webservers [Screenshot © BMD]")
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.
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).
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