Ausgangssituation:
Die Berechtigung für das Durchführen kryptographischer Aktionen soll im Live-Betrieb geprüft werden. Das Abfragen der Berechtigung soll mittels Abfrage eines LDAP-Verzeichnisdienstes realisiert werden.
Konfigurationsvorschlag
|
Durch diese Art des Implementierens wird beim Versand jeder einzelnen, kryptographisch zu behandelnden E-Mail eine LDAP-Abfrage gestartet. Trotz des cachens der Verbindung seitens des SEPPmail Secure E-Mail Gateways, kann dies unter Umständen zu erheblichen Performance Einbußen, beziehungsweise gegebenenfalls auch zum Überlasten des/r LDAP-Server/s führen. |
•Navigieren zu Mail Processing Ruleset generator Custom Commands Custom commands for outgoing e-mails BEFORE encryption:
•Aktivieren der Option, sowie Einfügen des folgenden Codes in das darunter liegende Eingabefeld:
Zeile |
Code |
|---|---|
01 |
# Begin: Custom commands for outgoing e-mails BEFORE encryption |
02 |
log(1,'Begin: Custom commands for outgoing e-mails BEFORE encryption'); |
|
|
03 |
# Begin: check if user is allowed to to send cryptographic e-mails |
04 |
log(1,'Begin: check if user is allowed to to send cryptographic e-mails'); |
|
|
05 |
setvar('ldap_bind','ldaps://myldap1.local,ldaps://myldap2.local;CN=ldapquery,OU=ServiceAccounts,OU=Benutzer,DC=customer1,DC=local;Kennwort;OU=Benutzer,DC=customer1,DC=local;(mail=$header_from)'); |
06 |
if (ldap_compare('$ldap_bind','memberOF','Secure E-Mail')) { |
07 |
if(authenticated()) { |
08 |
setuserattr('accountOptions','16'); |
09 |
} else { |
10 |
log(1,'$from is member of SecureMail, creating user, generating keys'); |
11 |
ldap_read('$ldap_bind','displayName','displayName'); |
12 |
ldap_read('$ldap_bind','sAMAccountName','sAMAccountName'); |
13 |
createaccount('0','$sAMAccountName','$displayName'); |
14 |
createkeys('@CREATEGPGKEYS@'); |
15 |
} |
16 |
} else { |
17 |
if(authenticated()) { |
18 |
log(1,'$from is not longer member of SecureMail, revoking permission to encrypt and/or sign e-mails'); |
19 |
setuserattr('accountOptions','5'); |
20 |
} else { |
21 |
log(1,'$from is not member of SecureMail, user does not exist, nothing to do'); |
22 |
} |
|
|
23 |
## force domain encryption - if available - for unlicensed users |
24 |
## only needed if "Always use S/MIME or OpenPGP if user keys areavailable" is selected |
25 |
## and "User creation" is not set to "Manual user creation: Only process outgoing mails from users with an account" |
26 |
if (domain_smime_keys_avail()) { |
27 |
log(1,'found S/MIME domain certificate for recipient(s) $header_to; $header_cc - trying to encrypt mail'); |
28 |
if (encrypt_domain_smime()) { |
29 |
log(1,'S/MIME Domain Encryption successful for recipient(s) $header_to; $header_cc'); |
30 |
deliver(); |
31 |
} else { |
32 |
log(1,'S/MIME Domain Encryption FAILED for recipient(s) $header_to; header_cc - trying OpenPGP Domain Encryption'); |
33 |
} |
34 |
} else { |
35 |
log(1,'no S/MIME domain certificate found for recipient(s) $header_to; $header_cc - trying OpenPGP Domain Encryption'); |
36 |
} |
|
|
37 |
if (domain_pgp_keys_avail()) { |
38 |
log(1,'found OpenPGP public domain key for recipient(s) $header_to; $header_cc - trying to encrypt mail'); |
39 |
if (encrypt_domain_pgp_mime()) { |
40 |
log(1,'OpenPGP Domain Encryption successful for recipient(s) $header_to; $header_cc'); |
41 |
deliver(); |
42 |
} else { |
43 |
log(1,'pgp domain encryption FAILED - going on without any action'); |
44 |
} |
45 |
} else { |
46 |
log(1,'Recipient(s) $header_to; $header_cc have no valid public OpenPGP key'); |
47 |
} |
48 |
log(1,'No domain encryption possible for $header_to; $header_cc, sending plain'); |
49 |
deliver(); |
|
|
50 |
## end forcing domain encryption |
51 |
} |
|
|
52 |
log(1,'End: check if user is allowed to to send cryptographic e-mails'); |
53 |
# End: check if user is allowed to to send cryptographic e-mails |
|
|
54 |
log(1,'End: Custom commands for outgoing e-mails BEFORE encryption'); |
55 |
# End: Custom commands for outgoing e-mails BEFORE encryption |
Beschreibung
In diesem Beispiel wird zunächst die statischen Parameter für die folgende LDAP-Abfrage in die Variable „ldap_bind“ geschrieben (Zeile 05). Über eine LDAP-Anfrage (in diesem Fall AD) wird die Zugehörigkeit des Absenders zur berechtigten Gruppe geprüft (Zeile 06). Ist der Absender berechtigt, so wird geprüft, ob er bereits ein Konto auf dem SEPPmail Secure E-Mail Gateway hat (Zeile 07). Ist ein Konto vorhanden, so werden diesem die Rechte für das Verschlüsseln/Signieren zugewiesen und die GINA Benachrichtigung gemäß den jeweiligen GINA Domain Einstellungen ausgelöst (Zeile 08). Andernfalls wird zunächst ein Log Eintrag (Zeile 10) erzeugt, der Windows Benutzer- und der Anzeigename aus dem AD ausgelesen und jeweils als Variable bereit gestellt (Zeile 11/12). Nun wird ein neues Benutzerkonto für den Absender erzeugt (Zeile 13). Dabei werden für „User ID“ und „Name“ die zuvor aus dem AD ausgelesenen Werte verwendet. Anschließend wird der neu angelegte User mit Schlüsselmaterial gemäß der Vorgabe aus Mail Processing Ruleset generator Key generation bestückt (Zeile 14).
Ist der Absender im Besitz eines Kontos auf dem SEPPmail Secure E-Mail Gateway, jedoch nicht mehr Mitglied der entsprechenden AD-Gruppe (Zeile 17), so wird dies im Log vermerkt (Zeile 18) und dem Benutzer die Rechte für das Verschlüsseln/Signieren entzogen (Zeile 19) (damit das Schlüsselmaterial auf der Appliance erhalten bleibt, wird das Konto lediglich deaktiviert, nicht gelöscht. Durch das Deaktivieren des Benutzerkontos wird die verwendete Benutzerlizenz wieder freigegeben). Das Entschlüsseln eventuell weiterhin eingehender E-Mails würde weiterhin funktionieren.
Für Absender, welche weder im Besitz eines Benutzerkontos, noch Mitglied der berechtigenden AD-Gruppe sind, ist keine Aktion erforderlich. Dies wird so in das Log eingetragen (Zeile 21).
Die durch die Kommentarzeilen ## force domain encryption und ## end forcing domain encryption eingegrenzten Befehle sind nur dann notwendig, wenn die Option „Always use S/MIME or OpenPGP if user keys are available“ des Abschnitts Mail Processing Ruleset generator Encryption/Decryption aktiviert wurde und Mail Processing Ruleset generator User creation nicht auf Do not create accounts (also disables custom commands for user creation) steht.
Hierdurch wird für den beschriebenen Konfigurationsfall gewährleistet, dass die Domänenverschlüsselung auch dann zum Tragen kommt, wenn vom Empfänger ein öffentlicher Domänenschlüssel vorhanden, der Absender jedoch nicht in der Gruppe der zum Verschlüsseln berechtigten Personen ist.
So wird zunächst geprüft, ob ein öffentlicher S/MIME Domänenschlüssel der Ziel-E-Mail Domäne(n) vorhanden ist (Zeile 26). Ist dies der Fall, so wird das protokolliert (Zeile 27) und die E-Mail an die Ziel-E-Mail-Domänen mit dem jeweiligen Schlüssel verschlüsselt (Zeile 28), im Log dokumentiert (Zeile 29) und die E-Mail ausgeliefert (Zeile 30). Schlägt das S/MIME-Domänenverschlüsseln fehl, so wird dies ebenso protokolliert (Zeile 32), als wenn kein S/MIME Schlüssel des/r Empfänger vorhanden ist (Zeile 35). Für diejenigen Empfängerdomänen, für die kein S/MIME Schlüssel bekannt ist, oder die Verschlüsselung fehlschlug, wird nun versucht, mit einem öffentlichen OpenPGP Domänenschlüssel zu verschlüsseln. Auch hier wird zunächst geprüft, ob ein öffentlicher OpenPGP Domänenschlüssel der Ziel-E-Mail Domäne(n) vorhanden ist (Zeile 37). Ist dies der Fall, so wird das protokolliert (Zeile 38) und die E-Mail an die Ziel-E-Mail Domänen mit dem jeweiligen Schlüssel verschlüsselt (Zeile 39), im Log dokumentiert (Zeile 40) und die E-Mail ausgeliefert (Zeile 41). Schlägt die Verschlüsselung fehl, so wird dies ebenso protokolliert (Zeile 43), als wenn kein OpenPGP Schlüssel des/r Empfänger vorhanden ist (Zeile 46).
Sofern nicht bereits aufgrund einer erfolgreichen Domänenverschlüsselung ausgeliefert wurde, wird unverschlüsselt versendet (Zeile 49), ungeachtet eventuell vorhandener Steuerkennzeichen (siehe Steuern der Appliance). Dieses Verhalten kann natürlich durch entsprechenden Zusatzcode bei Bedarf ebenfalls angepasst werden.
Verwendete
Befehle
