CDS Access Control (DCL): Feingranulare Berechtigungen

kategorie
CDS
Veröffentlicht
autor
Johannes

CDS Access Control ermöglicht die Definition von Berechtigungsprüfungen direkt auf CDS View-Ebene. Mit der Data Control Language (DCL) werden Zugriffsregeln deklarativ definiert, die automatisch bei jedem Zugriff auf den View angewendet werden.

Grundkonzept

Access Control in CDS verlagert die Berechtigungsprüfung von der Anwendungslogik in die Datenbank-Schicht:

Klassische PrüfungCDS Access Control
AUTHORITY-CHECK im CodeDCL-Definition am View
Manuell bei jedem ZugriffAutomatisch bei SELECT
Leicht zu vergessenImmer aktiv
Imperativer CodeDeklarative Regeln
Schwer zu wartenZentral definiert

Vorteile

  • Zentrale Definition: Berechtigung einmal definiert, überall wirksam
  • Keine Vergesslichkeit: Zugriff ohne Berechtigung unmöglich
  • Performance: Optimierung durch DB-Pushdown
  • Transparenz: Regeln direkt am View sichtbar

Access Control Definition

Eine Access Control Definition ist ein separates CDS-Artefakt mit der Endung .dcl:

@EndUserText.label: 'Access Control für Bestellungen'
@MappingRole: true
define role ZI_Order {
grant select on ZI_Order
where ( CompanyCode ) = aspect pfcg_auth( Z_BUKRS, BUKRS, ACTVT = '03' );
}

Struktur einer DCL

ElementBeschreibung
define roleDefiniert eine Zugriffsrolle
grant select onGewährt Lesezugriff auf den View
whereBedingung für Datenzugriff
aspectBerechtigungsaspekt (z.B. PFCG)

PFCG-Autorisierung

Der häufigste Anwendungsfall ist die Integration mit PFCG-Berechtigungsobjekten:

@EndUserText.label: 'Sales Order Access'
@MappingRole: true
define role ZI_SalesOrder {
grant select on ZI_SalesOrder
where ( SalesOrganization ) =
aspect pfcg_auth( V_VBAK_VKO, VKORG, ACTVT = '03' );
}

Parameter des pfcg_auth Aspects

aspect pfcg_auth(
<Berechtigungsobjekt>,
<Feld im Objekt>,
<Aktivität> = '<Wert>'
)
  • Berechtigungsobjekt: Name des PFCG-Objekts (z.B. V_VBAK_VKO)
  • Feld im Objekt: Zu prüfendes Feld (z.B. VKORG)
  • Aktivität: ACTVT-Wert (01=Anlegen, 02=Ändern, 03=Anzeigen)

Mehrere Felder prüfen

@MappingRole: true
define role ZI_Material {
grant select on ZI_Material
where ( Plant, MaterialType ) =
aspect pfcg_auth( M_MATE_WRK, WERKS, MTART, ACTVT = '03' );
}

Komplexe Bedingungen

AND-Verknüpfung

define role ZI_PurchaseOrder {
grant select on ZI_PurchaseOrder
where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' )
and ( PurchasingOrganization ) = aspect pfcg_auth( M_BEST_EKO, EKORG, ACTVT = '03' );
}

OR-Verknüpfung

define role ZI_Document {
grant select on ZI_Document
where ( DocumentType ) = aspect pfcg_auth( Z_DOCTYPE, BSART, ACTVT = '03' )
or ( DocumentType ) = 'PUBLIC';
}

Kombinierte Logik

define role ZI_Order {
grant select on ZI_Order
where (
( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' )
and ( ( SalesOrg ) = aspect pfcg_auth( V_VBAK_VKO, VKORG, ACTVT = '03' )
or Status = 'RELEASED' )
);
}

Pfad-Ausdrücke für Assoziationen

Bei hierarchischen Daten kann die Berechtigung über Assoziationen geprüft werden:

@AccessControl.authorizationCheck: #CHECK
define view entity ZI_OrderItem
as select from zorder_item
association [1..1] to ZI_Order as _Order
on $projection.OrderID = _Order.OrderID
{
key OrderID,
key ItemNumber,
Material,
Quantity,
_Order
}

Die DCL prüft über den Pfad:

define role ZI_OrderItem {
grant select on ZI_OrderItem
where ( _Order.CompanyCode ) =
aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

Tiefe Pfade

define role ZI_OrderItemSchedule {
grant select on ZI_OrderItemSchedule
where ( _OrderItem._Order.CompanyCode ) =
aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

Aspekt-basierte Berechtigungen

Eigene Berechtigungsaspekte

Neben pfcg_auth können eigene Aspekte definiert werden:

@EndUserText.label: 'User Country Aspect'
define abstract entity ZA_UserCountry
{
Country : land1;
}

Verwendung in DCL:

define role ZI_Customer {
grant select on ZI_Customer
where Country = aspect ZA_UserCountry.Country;
}

Inherit Aspect

Der inherit Aspect übernimmt die Berechtigungen einer Basisentität:

define role ZC_SalesOrder {
grant select on ZC_SalesOrder
where inherits_all;
}

Dies bedeutet: Der Projection View erbt die DCL des zugrundeliegenden Interface View.

Kontextabhängige Berechtigungen

Benutzerattribute

define role ZI_Employee {
grant select on ZI_Employee
where PersonnelArea IN
aspect pfcg_auth( PLOG, PERSA, ACTVT = '03' )
or EmployeeID = $session.user;
}

Systemvariablen

VariableBeschreibung
$session.userAktueller Benutzer
$session.clientAktueller Mandant
$session.system_dateSystemdatum
$session.system_languageAnmeldesprache
define role ZI_PersonalData {
grant select on ZI_PersonalData
where CreatedBy = $session.user
or Visibility = 'PUBLIC';
}

Access Control am View aktivieren

Der CDS View muss die Access Control Prüfung aktivieren:

@AccessControl.authorizationCheck: #CHECK
define view entity ZI_SalesOrder
as select from zsalesorder
{
key SalesOrderID,
SalesOrganization,
Customer,
NetAmount
}

authorizationCheck-Optionen

WertBeschreibung
#CHECKDCL wird geprüft, Warnung wenn keine DCL existiert
#NOT_REQUIREDKeine Prüfung erforderlich
#NOT_ALLOWEDDCL darf nicht existieren
#PRIVILEGED_ONLYNur privilegierter Zugriff erlaubt

Privilegierter Zugriff

Für Systemoperationen kann die Access Control umgangen werden:

" Mit privilegiertem Zugriff (DCL wird ignoriert)
SELECT * FROM zi_salesorder
WITH PRIVILEGED ACCESS
INTO TABLE @DATA(lt_orders).
" Normaler Zugriff (DCL wird angewendet)
SELECT * FROM zi_salesorder
INTO TABLE @DATA(lt_orders_filtered).

Wann privilegierten Zugriff verwenden?

  • Batch-Verarbeitung: Hintergrundjobs ohne Benutzerkontext
  • Systemintegration: RFC/API-Aufrufe aus anderen Systemen
  • Reporting: Aggregierte Auswertungen
  • Administration: Systemweite Operationen

Hierarchische Views

Bei View-Hierarchien wird die DCL auf jeder Ebene geprüft:

ZC_SalesOrder (Projection)
↓ Prüft eigene DCL (kann inherit nutzen)
ZI_SalesOrder (Interface View)
↓ Prüft eigene DCL
ZSALESORDER (Tabelle)

Best Practice: DCL-Strategie

-- Interface View: Volle Berechtigungsprüfung
define role ZI_SalesOrder {
grant select on ZI_SalesOrder
where ( SalesOrg ) = aspect pfcg_auth( V_VBAK_VKO, VKORG, ACTVT = '03' );
}
-- Projection View: Erbt von Interface View
define role ZC_SalesOrder {
grant select on ZC_SalesOrder
where inherits_all;
}

Vergleich zu klassischen Authority-Checks

Klassischer Ansatz

METHOD get_sales_orders.
" Manuell Berechtigung prüfen
AUTHORITY-CHECK OBJECT 'V_VBAK_VKO'
ID 'VKORG' FIELD lv_sales_org
ID 'ACTVT' FIELD '03'.
IF sy-subrc <> 0.
RAISE EXCEPTION TYPE cx_no_authority.
ENDIF.
" Dann Daten lesen
SELECT * FROM zsalesorder
WHERE vkorg = @lv_sales_org
INTO TABLE @rt_orders.
ENDMETHOD.

CDS Access Control Ansatz

METHOD get_sales_orders.
" DCL prüft automatisch - nur berechtigte Daten zurückgegeben
SELECT * FROM zi_salesorder
INTO TABLE @rt_orders.
ENDMETHOD.

Debugging und Analyse

Access Control Trace

Im ADT kann der Access Control Trace aktiviert werden:

  1. Window → Show View → Other → Access Control Trace
  2. Trace starten
  3. View abfragen
  4. Trace analysieren

SQL Statement analysieren

" Generated SQL mit DCL-Bedingungen anzeigen
DATA(lo_sql) = cl_sql_statement=>create_for_cds_entity(
iv_cds_entity = 'ZI_SALESORDER' ).
DATA(lv_sql) = lo_sql->get_native_sql( ).

Performance-Aspekte

Index-Nutzung

DCL-Bedingungen werden in WHERE-Klauseln übersetzt. Für gute Performance:

-- Gut: Feld mit Index
define role ZI_Order {
grant select on ZI_Order
where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}
-- Schlecht: Komplexe Ausdrücke ohne Index
define role ZI_Order {
grant select on ZI_Order
where SUBSTRING( OrderNumber, 1, 2 ) = 'AB';
}

Pfad-Ausdrücke optimieren

-- Performance: Kurze Pfade bevorzugen
where _Order.CompanyCode = ...
-- Weniger performant: Tiefe Pfade
where _OrderItem._Order._Customer._Country.Region = ...

Häufige Muster

Eigene Daten sehen

define role ZI_MyDocuments {
grant select on ZI_MyDocuments
where CreatedBy = $session.user
or AssignedTo = $session.user;
}

Öffentliche und eigene Daten

define role ZI_Announcement {
grant select on ZI_Announcement
where Visibility = 'PUBLIC'
or ( Visibility = 'PRIVATE' and Owner = $session.user );
}

Zeitbasierte Berechtigung

define role ZI_Campaign {
grant select on ZI_Campaign
where ValidFrom <= $session.system_date
and ValidTo >= $session.system_date;
}

Best Practices

EmpfehlungBegründung
DCL am Interface View definierenZentrale Stelle für Berechtigungslogik
inherits_all für ProjectionsKonsistente Berechtigungen
Index auf BerechtigungsfelderPerformance bei großen Datenmengen
PFCG-Objekte wiederverwendenIntegration mit Rollenverwaltung
#CHECK als StandardSicherheit durch Pflichtprüfung
Pfade kurz haltenBessere Performance
Privileged Access sparsam einsetzenSicherheitsrisiko minimieren

Zusammenfassung

CDS Access Control mit DCL bietet:

  • Deklarative Berechtigungen: Regeln direkt am CDS View definiert
  • Automatische Prüfung: Kein Vergessen von Authority-Checks möglich
  • PFCG-Integration: Nutzung bestehender Berechtigungsobjekte
  • Pfad-Ausdrücke: Berechtigungen über Assoziationen prüfen
  • Performance: Optimierung durch DB-Pushdown

DCL ist der moderne Ansatz für Datensicherheit in ABAP Cloud und sollte für alle CDS Views mit sensiblen Daten verwendet werden.

Weiterführende Themen