Programmschutz und Tabellenschutz (Teil3)

Im Teil 3 kommen wir nun zur äquivalenten Umsetzung der Idee des Programmschutzes (Teil2); nun aber für die Tabellen.

Tabellen werden normalerweise mit SE16 oder SM30 angezeigt oder gepflegt. Beide Transaktionen haben ein Einstiegsbild und ggf. ein Selektionsbild, mit dem man den Inhalt der Tabelle ändern kann. Meist werden für die Auswahl von häufig benutzen Tabellen Varianten im System gespeichert, damit die Anzeige standardisiert ist, und man sich Arbeit um das Wissen, welches  Feld was bedeutet,  sparen kann.

Genau das Geiche geht auch über sog. Parametertransaktionen.

Wie schon im Teil2 bei den Programmen nehmen wir die gleiche Idee auf:  Tabellen werden normalerweise nur von dem Objekt S_TABU_DIS geschützt. Neben der Aktivität (ACTVT) wird noch eine Berechtigungsgruppe unterschieden. Ist diese Gruppe in der TDDAT nicht gefüllt, kann man als Berechtigungsgruppe &NC& eingeben und bezieht sich auf alle Tabellen ohne Eintrag in der TDDAT.

Um nun einen Tabellenschutz aufzubauen – denn es gibt eine ganze Reihe von schützenswerten Tabellen – kann man statt der Vergabe von Berechtigungsgruppen auch eine Transaktion definieren. Dies wäre dann eine sog. Parametertransaktion.

Man definiert eine Parametertransaktion mit der SE93, indem man sie als „Transaktion mit Parametern (Parametertransaktion) auswählt. Auf dem 2. Bild der SE93 vergibt man dann als Transaktionsname den Namen SM30 oder SE16.

Damit definiert man, dass die SM30 für diese neue Transaktion aufgerufen wird. Man kann noch auswählen, dass das Einstiegsdynpro der Transaktion (SM30 oder SE16) übersprungen wird. Dies sollte man tun, da die neue Transaktion ja nur für eine einzige Tabelle aufrufen soll.

Im unteren Bereich des Dynpros der SE93 vergibt man nun die Tabelle, die man anzeigen oder ändern will:

Für die Anzeige vergibt man:       SHOW=X und VIEWNAME=xxxx
Im Falle des Updates vergibt man UPDATE=X und VIENAME=xxxx

Eine genaue Beschreibung der einzelnen Eingabemöglichkeiten finden Sie hier.

In der neuen Transaktion kann man dann ggf. über das Menü auch Selektionsvarianten der Anzeige vergeben.

Soweit zur Definition der Transaktion.

Berechtigungstechnisch wird hier die Transaktion SM30 im Hintergrund aufgerufen, ohne dass man eine Berechtigung für diese Transaktion im Berechtigungsobjekt S_TCODE  benötigt. Was aber abgeprüft wird,  ist das Objekt S_TABU_DIS. Hier muß bei einer Pflegetransaktion sicherlich die ACTVT=01,02,03,06… vergeben werden. Als Berechtigungsgruppe (DICBERCLS) vergibt man &NC&, da die Tabelle in der TDDAT keiner Berechtigungsgruppe zugeordnet wird und bei ihrer Erstellung in der SE11 auch keine Berechtigunggruppe vergeben werden sollte.

Jetzt hat man für die Anzeige und Pflege  zwei unterschiedliche Transaktionen definiert, die jeweils in 2 unterschiedliche Rollen aufgenommen werden, um die Pflege und die reine Anzeige getrennt zu steuern.

Mit einem Eintrag in unser Firmenmenü (SE43N) kann sich nun jeder Benutzer entweder die Pflege- oder die Anzeigetransaktion in seine Favoriten legen. Ob er die Berechtigung zur Pflege hat, entscheidet die Rolle des Benutzers, nicht das Vorkommen im Menü.

In allen anderen Rollen wird nun die Transaktionsberechtigung für die SM30 und SE16 gestrichen, und man hat einen optimalen Schutz aufgebaut. Varianten der Transaktion werden ja sowieso nur von der Entwicklung oder der Administration aufgebaut, so dass auch die Variantendefinition geschützt ist.

Falls Sie zu dieser Lösung noch Fragen haben, können Sie mich gerne anmailen (bk[at]sybeklue.de). Ich werde noch einen Newsletter erstellen, um registrierte Benutzer in www.sybeklue.de mit einer Schritt für Schritt Anleitung zu beliefern.

Gruß

Bernd Klüppelberg

P.S. Bitte beachten Sie den Kommentar von Dieter Gödel (SAP)

4 Responses to “Programmschutz und Tabellenschutz (Teil3)”

  1. Hallo,

    die Idee ist ja gut, aber es scheidert daran, dass Sie nicht wissen, welche Tabellen der Benutzer nutzt. Nun sind manche Kunden mit 10.000 zu groß, um die Anwender nach, die von Ihnen benutzten Tabellen zu fragen, die dann als Paramtertransaktion umgesetzt werden könnten. Was schlagen Sie vor?

    Gruß
    Marcel

  2. Hallo Marcel,

    danke für den Kommentar.

    Es muss doch bei den normalen Anwendern – nicht den Administratoren oder Consultern – herauszufinden sein, auf welche Tabellen sie wie zugreifen müssen!
    Das darf doch kein Argument für ein völlig offenes System sein. Und bei mehr als 100.000 Transaktionen fallen doch 10 000 weitere nicht weiter auf, oder!
    Gut ich weis, dass das ein enormer Aufwand ist, doch der Aufwand dürfte geringer sein, als die Bewertungen in der TDDAT hinzubiegen.

    Gruß
    Bernd Klüppelberg

  3. Hallo Bernd,
    das Problem haben wir verstanden und im Ansatz gelöst. Kann das neue Objekt S_TABU_NAM (seit Hinweis 1481950) in das Kapitel mit aufgenommen werden? Im Zweifelsfall einfach nochmal bei mir nachfragen. Viele Grüsse,
    Dieter.

  4. Hallo Dieter,
    Willkommen auf meinem Blog und danke für den Hinweis! Das kann einiges einfacher machen! Ich werde das neue Berechtigungsobjekt S_TABU_NAM testen und hoffentlich bald darüber im Blog berichten können.

    Gruß
    Bernd

Schreiben Sie bitte einen Kommentar





SAP Berechtigungen, -Konzepte, -Technik | System Beratung Bernd Klüppelberg