Mandantenfilterung

Mandantenfilterung

Im Folgenden wird der Begriff Zertifikat als Synonym für Zertifikat oder Schlüssel verwendet.

Es ist möglich, die Arbeit mit dem FSS (Fastlane Security Server) nach Mandanten gefiltert anzuzeigen und nur so zu bearbeiten. Falls das Feature aktiviert wird, bedeutet dies im Einzelnen:

  • Beim Zertifikatsupload wird das Zertifikat dem Mandanten des eingeloggten Users zugeordnet.
  • Der User sieht in der Zertifikatsverswaltung nur Zertifikate, die seinem Mandanten zugeordnet sind. Entsprechend kann er auch nur diese bearbeiten oder löschen.
  • ILNs und Email-Adressen der Systeme werden Mandanten zugeordnet. Bei der Nachrichtenverarbeitung wird der Mandant des angesprochenen Systems identifiziert. Es werden nur die Zertifikate benutzt, die diesem Mandanten zugeordnet sind. Ein System ist der Empfänger einer eingehenden Nachricht, bzw. der Absender einer ausgehenden Nachricht. ** Inbound wird die ILN zunächst auf Basis der Extension SENDER_EMAIL (FROM_=) und alternativ auf Basis des Mail-Betreffs ermittelt.
  • Ein Adminuser kann alle Zertifikate sehen. Beim Upload eines Zertifikats kann er dieses einem beliebigen Mandanten zuordnen.
  • Analog zur mandantenscharfen Zertifikatsverwaltung werden auch die Regeln des Regelwerks mandantenscharf konfiguriert und ausgewertet.

Um das Feature zu aktivieren, müssen folgende Anpassungen am Customizing durchgeführt werden:

FSS-Tabelle client

Verfügbare Mandanten werden in der FSS-Tabelle client aufgelistet. Die Mandanten müssen per Insert-SQL angelegt werden. Für die einzelnen Spalten gilt:

  • id Primärschlüssel
  • name eindeutiger Name des Mandanten, case-sensitive
  • description kann beliebig gefüllt werden

Beispiel:

INSERT INTO client (id, name, description) VALUES (6, 'lief', 'Lieferant');

Vergleiche hierzu auch den Abschnitt “Migration der Zertifikate”.

Extension MANDANT_CONFIGURATION

Mit Hilfe der Extension MANDANT_CONFIGURATION werden die verfügbaren Mandanten auf Seiten der B2B definiert sowie die Zuordnung zwischen System und Mandant hergestellt. Ein System kann durch die Email-Adresse oder bei AS2 durch eine ILN repräsentiert werden. Die Zuordnung wird insbesondere bei der Nachrichtenverarbeitung benötigt. Ein Mandant muss einem Eintrag in der FSS-Tabelle client.name entsprechen. Die Angaben zum Mandanten sind Case-Sensitive.

Beispiel:

mandants=netz,lief,msb

ago-netz-energy@b2bbp.org=netz

ago-lief-energy@b2bbp.org=lief

9912345678901=netz

Migration der Zertifikate

Falls eine B2B bisher mit einem FSS ohne Mandantenfilterung betrieben wurde und diese nun eingeführt werden soll, kann eine Migration der vorhandenen Zertifikate durchgeführt werden. Falls auf die Migration verzichtet wird, können die neuen Mandanten nicht mehr die bisher eingespielten Zertifikate nutzen; entsprechend müssen alle Zertifikate erneut eingespielt werden.

Bisher wurden Zertifikate intern dem Mandanten UNDEFINED zugeordnet. Diese Zuordnung kann in der Datenbank des FSS geändert werden: hierfür ist der entsprechende Eintrag in der Tabelle client, Spalte name anzupassen. Sobald die Zertifikate dem neuen Mandanten zugeordnet sind, kann dieser auf sie zugreifen.

Alle weiteren, bisher fehlenden Mandanten sind als Einträge in der Tabelle “client” anzulegen.

Die folgenden Schritte erfordern ein grundlegendes Verständnis von Fremdschlüsselbeziehungen in Datenbanken. Die Zertifikate sind in der Tabelle certstore gespeichert. Diese Tabelle hat eine Fremdschlüsselbeziehung zur Tabelle client.

Falls unterschiedliche vorhandene Zertifikate unterschiedlichen Mandanten zugeordnet werden sollen, kann dies mit Hilfe der Datenbank umgesetzt werden. Hierfür ist die Fremdschlüsselbeziehung entsprechend anzupassen: jedes Zertifikat muss genau dem zugehörigen Mandanten zugeordnet sein.

Falls ein Zertifikat mehreren Mandanten zugeordnet werden soll, kann dies mit Hilfe der Datenbank umgesetzt werden. Das Zertifikat in der Tabelle certstore muss kopiert werden. Anschließend kann die Fremdschlüsselbeziehung zur Tabelle client gemäß der zusätzlichen Mandanten angepasst werden.

Example with Postgres (database version 12)

-- before: certificates with client = undefined
-- goal: all certificates assigned to both clients netz and lief

-- set client to netz (id=2)
update certstore
set clientid = 2;

-- copy entries into tmp-table
SELECT *
INTO certstore_tmp
FROM certstore;

-- set client of copies to lief (id=3)
update certstore_tmp
set clientid = 3;

-- move copies back to original table (all columns but not id column)
insert into certstore (alias_id, slicefrom, sliceto, clientid, certificate, email, validfrom, validto, active, state, description, ski, thumbprint, storedonhsm, revocation, privatekey, publickeytoprivatekey)
select alias_id, slicefrom, sliceto, clientid, certificate, email, validfrom, validto, active, state, description, ski, thumbprint, storedonhsm, revocation, privatekey, publickeytoprivatekey
from certstore_tmp;

-- delete tmp-table
drop table certstore_tmp;

-- update certificate_purpose
insert into certificate_purpose(certificate, purpose)
(select id, 'ENC'
from certstore
where clientid = 3);

insert into certificate_purpose(certificate, purpose)
(select id, 'SIGN'
from certstore
where clientid = 3);

Example with Oracle (database version 6)

-- before: certificates with client = undefined
-- goal: all certificates assigned to both clients netz and lief

-- set client to lief (id=21)
update certstore set clientid = 21;

--  copy with netz (id=22)
insert into certstore (id, alias_id, slicefrom, sliceto, type, 22, certificate, email, validfrom, validto, active, state, description, ski, thumbprint, revocation, storedonhsm)
select hibernate_sequence.nextval, alias_id, slicefrom, sliceto, type, clientid, certificate, email, validfrom, validto, active, state, description, ski, thumbprint, revocation, storedonhsm
from certstore
where clientid = 21;

Example with Oracle (database version 12)

-- before: certificates with client = undefined
-- goal: all certificates assigned to both clients netz and lief

-- set client to lief (id=41)
update certstore set clientid = 41

--  copy with netz (id=42)
insert into certstore (id, alias_id, slicefrom, sliceto, clientid, certificate, email, validfrom, validto, active, state, description, ski, thumbprint, revocation, storedonhsm, privatekey, publickeytoprivatekey)
select hibernate_sequence.nextval, alias_id, slicefrom, sliceto, 42, certificate, email, validfrom, validto, active, state, description, ski, thumbprint, revocation, storedonhsm, privatekey, publickeytoprivatekey
from certstore
where clientid = 41;

-- update certificate_purpose
insert into certificate_purpose(certificate, purpose)
(select id, 'ENC'
from certstore
where clientid = 42);

insert into certificate_purpose(certificate, purpose)
(select id, 'SIGN'
from certstore
where clientid = 42);

Regelwerk

Jede Regel im Regelwerk ist einem und nur einem Mandanten zugeordnet. Das bedeutet, dass eine Regel für jeden Mandanten einzeln konfiguriert werden muss.

Falls Regeln definiert wurden, bevor die Mandantenfilterung installiert wurde (oder falls Regeln definiert wurden, bevor das mandantenscharfe Regelwerk released wurde, geplant für März 2019 mit Ticket FSS-51), müssen die Regeln erneut für jeden Mandanten angelegt werden. (Alle alten Regeln werden dem ungenutzten Mandanten ‘undefined’ zugeordnet. Ein Admin kann diese Regeln noch sehen.)

Ein Mandanten-User kann nur Regeln für seinen eigenen Mandanten sehen & konfigurieren. Ein Admin kann die Regeln aller Mandanten sehen & konfigurieren.

Eine Regel wird nur dann bei einer Nachricht ausgewertet, wenn der Mandant der Nachricht mit dem Mandanten der Regel übereinstimmt.

View Me   Edit Me