Das Tool „Command Control“ als dritter Schutzwall für IBM i

Kommandos besser absichern

Sicherheit war im langen Leben der IBM-Familie von Midrange-Servern schon immer ein heißes Eisen. Und das, obwohl die AS/400 und ihre Nachfolger bei allen IT- und Sicherheitsfachleuten, die ihren Job verstehen, durchaus als Systeme gelten, die dank ihres integrierten Betriebssystems sehr mächtige und gleichzeitig auch flexible Implementierungen von Datenschutz- und -sicherungsmaßnahmen erlauben.

„Doch auch beim Fort Knox unter den Servern bleiben Sicherheitsprobleme offen, die es zu adressieren gilt“, weiß Diplomingenieur Olaf Vogelbusch. Das Essener Softwarehaus Vogelbusch GmbH hat daher seit Jahren die Netzwerk- und Datenschutzsoftware für diese Plattform des israelischen Softwarehauses Enforcive (früher Bsafe) im Produktportfolio. „Eines dieser Probleme sind die Kommandos des jetzt IBM i genannten Betriebssystems und die Überlegungen, ihre Nutzung durch die User möglichst wenig zu beeinträchtigen und dennoch ein Hochsicherheitssystem aufzusetzen“, so Vogelbusch weiter.

Hierbei steht die Einschränkung des Zugriffs durch das Wissen des Nutzers im Vordergrund – eine in Form von Nutzerkennung und Passwort häufig geübte Praxis, mit der sich das Sicherheitsniveau effektiv erhöhen lässt. Bei der konkreten Implementierung dieser Praxis tauchen aber oft Schwierigkeiten auf, insbesondere bei der Absicherung von Systemkommandos. Zwar sind die Fähigkeiten des Betriebssystems IBM i dank seiner Objekt­basiertheit hierfür ausgesprochen gut ausgebildet, doch reichen selbst diese Fähigkeiten nicht aus.

Zwei Schutzmechanismen für Kommandos reichen nicht

In IBM i sind neben den umfassenden Datenschutzfunktionen gleich zwei Schutzmechanismen speziell für Kommandos eingebaut. Den ersten Schutzwall bildet die mächtige Objektverwaltung mit ihrer Möglichkeit, jedem einzelnen Kommando unterschiedliche Zugriffsoptionen – Nutzung, Änderung und Verwaltung – für einzelne User oder auch Nutzerprofile zu erlauben. Diese Profile werden meistens genutzt, um die Autorisierung für bestimmte Anwendungen in Gruppen zu bündeln. Das ist jedoch etwas anderes als die Unterscheidung zwischen privilegierten Systemadministratoren und „einfachen Usern“. Der zweite Schutzwall ist das Systemjournal, mit dem sich die Nutzung von Kommandos systemweit (oder auch für bestimmte User) überwachen und dokumentieren lässt.

Das ist zwar besser als nichts (wie bei anderen Systemen), aber immer noch weit entfernt von einem perfekten Schutz – weil beide Schutzwälle Schwachstellen haben. „Im Systemjournal lässt sich das Auditing für Kommandos nur einzeln für bestimmte User einrichten“, erklärt Olaf Vogelbusch. „Das ist zwar hilfreich, wenn ein kleine Anzahl von Usern bei sehr vielen Kommandos überwacht werden soll, nicht aber wenn es darum geht, sehr viele User bei wenigen, sensiblen Kommandos zu überwachen.“

Soll der Zugriff einzelner User auf bestimmte Kommandos über die Objektverwaltung kontrolliert werden, sieht der Essener IT-Experte Vogelbusch bei großen Systemen ein Problem in der enormen Vielzahl von Definitionen, die dafür nötig wären. Der Einsatz von Gruppenprofilen und zusätzlichen Benutzergruppen könne zwar eine gewisse Hilfe sein, erhöhe aber auch die Wahrscheinlichkeit, dass irgendein Benutzergruppenprofil versehentlich die Autorität für sämtliche Objekte (*ALLOBJ) erhält und so unerwartete Schwachpunkte in die Systemsicherheit einbaut.

Auch die Power-User dürfen nicht alles


Das größte Sicherheitsproblem bei der Nutzung von Kommandos sind die sogenannten „Power-User“, wie z.B. User mit der Berechtigung *ALLOBJ oder QSECOFR. Power-User haben die Berechtigung für sämtliche Aktionen auf allen Objekten, weil für sie alle in der Objektverwaltung festgelegten Berechtigungen aufgehoben sind. Das ist ebenso allgemein bekannt wie die Tatsache, dass jedermann sein Passwort absolut geheim halten sollte, aber dennoch graue Theorie; in der Praxis lassen sich Passwörter oft sehr einfach erraten oder finden sich gar auf einem Notizzettel am Bildschirm.

Dieses Problem adressiert Enforcive durch einen dritten Schutzwall beim Einsatz von Systemkommandos, der die Objektverwaltung des Betriebssystems ergänzt. Das Tool „Command Control“ kann zwar die Systemeinstellungen für die Objekte nicht außer Kraft setzen, aber so untermauern, dass nicht einmal User mit *ALLOBJ-Berechtigung (inklusive QSECOFR) eine geschützte Aktion darauf ausführen können.

Das ist nicht nur ein Schutz gegen böswillige Individuen, die sich in das System gehackt haben, sondern auch gegen Irrtümer und Bedienfehler, etwa Tippfehler oder Verwechslungen von Kommandos. Auch falsch platzierte Kommandos in CL-Programmen oder Pannen bei Experimenten mit ungewohnten Kommandos haben dann keine fatalen Konsequenzen mehr.

Außerdem vereinfacht diese Sicherheitslösung von Enforcive das Identitätsmanagement durch maßgerechte „User Groups“. Die sind viel einfacher zu verstehen und zu handhaben als Gruppenprofile und das Konzept von primären und ergänzenden Nutzergruppen, weil sie zum einen außerhalb des Userprofils verwaltet werden und weil zum anderen der User einer Gruppe zugeordnet wird und nicht wie in der Objektverwaltung die Gruppe eine Eigenschaft des Users ist.

www.vogelbusch.de

Bildquelle: Thinkstock

©2020Alle Rechte bei MEDIENHAUS Verlag GmbH

Unsere Website verwendet Cookies, um Ihnen den bestmöglichen Service zu bieten. Durch die weitere Nutzung der Seite stimmen Sie der Verwendung zu. Weitere Infos finden Sie in unserer Datenschutzerklärung.

ok