Zum Inhalt wechseln


Foto

Vertrauliche Dokumente vor Admin schützen


  • Bitte melde dich an um zu Antworten
42 Antworten in diesem Thema

#1 tomw

tomw

    Newbie

  • 63 Beiträge

 

Geschrieben 06. Februar 2012 - 10:26

Darf ich nach ein paar Sichworten oder Ideen Freagen wie man höchst vertrauliche Daten (zB HR) vor unberechtigtem Zugriff, auch durch Sysadmins, schützen kann.

Es gibt Daten die auch für die EDV Abteilung unzugänglich sein sollen, aber trotzdem natürlich gesichert werden müssen.

Vertrauens/Mistrauensdiskussionen nützen hier nicht, die Daten sind zu schützen.

Danke

#2 NorbertFe

NorbertFe

    Expert Member

  • 30.605 Beiträge

 

Geschrieben 06. Februar 2012 - 10:31

Waren in den anderen Threads dazu nicht genügend Infos? Verschlüsselung ist eigentlich das, was du suchst, nur da sollte auch jemand den "Masterkey" haben, um im Fall der Fälle eine Entschlüsselung vornehmen zu können.

Bye
Norbert

Make something i***-proof and they will build a better i***.


#3 djmaker

djmaker

    Board Veteran

  • 3.455 Beiträge

 

Geschrieben 06. Februar 2012 - 16:35

Etwas granularer geht es hiermit:

Active Directory-Rechteverwaltungsdienste (Übersicht)
Thomas

K.Y.S.S. - Keep Your Signatur Short :)

#4 MrCocktail

MrCocktail

    Board Veteran

  • 1.214 Beiträge

 

Geschrieben 08. Februar 2012 - 10:06

*hust*
Ein Admin ist ein Admin ist ein Admin.
Das kannst du nur auf Orga Ebende machen, wenn ein AG das nicht versteht, zeige es ihm. Für jede eingesetzte Lösung muss es die möglichkeit eines Restores durch den Admin geben, wenn die Daten archiviert werden müssen.
Ansonsten Papierakten.

#5 jarazul

jarazul

    Board Veteran

  • 636 Beiträge

 

Geschrieben 08. Februar 2012 - 10:23

Mittels ADRMS bzw. EFS (not preferred) kann bei vorhandenem Rechte Modell ein Administrator administrieren ohne Zugriff auf die geschützten Dokumente zu haben. Es können aber nicht alle Filetypen geschützt werden.

AD RMS Supported Files - Active Directory Rights Management Services - AD RMS - Site Home - MSDN Blogs

Ein Dienstkonto das analog zu einem DRA (Data Recovery Agent) die Files im Notfall natürlich öffnen sollte, ist vielleicht ebenso notwendig wie ein Dienstkonto zum Backup / Restore.

Auch Lösungen die heikle Files in ein Archiv-System aufnehmen (inkl. Retention Policies etc) und mit Berechtigungen des Archiv-Systems vor Admins / unerwünschten Personen schützen, habe ich schon im Einsatz gesehen.

Und nein, nur weil jemand "Admin" ist (welche Rolle ist das bei der Definition eigt), muss diese Person nicht immer Zugriff auf alles bekommen bzw. die Möglichkeit haben sich diesen Zugriff zu beschaffen.

Ebenso, wie ein Vorredner anmerkte, kann auch der Einsatz von organisatorischen Richtlinien sinnvoll sein. Nach dem Motto "Vertrauen ist gut, Kontrolle ist besser" sollte aber auch ein geeigneter technologischer Schutz auf Basis von den Anforderungen (wie lauten die eigt genau) umgesetzt werden.
MCTS: ConfigMgr 2007
MCITP EA / SA / EDA
ITIL v3 Foundation

#6 zahni

zahni

    Expert Member

  • 16.390 Beiträge

 

Geschrieben 08. Februar 2012 - 12:17

Alls schön und gut. Wenn die Daten dann auf dem Band liegen, kommt der Admin trotzdem ran (zumindest Der von der Datensicherung).

Wenn es "sicher" sein soll, hilft nur Verschlüsselung mit Kennwörtern bzw. Key's, die nur der User kennt. Mit allen Risiken, incl. Datenverlust beim Verlust selbiger.

Wen du nicht mit Können beeindrucken kannst, den verwirre mit Schwachsinn!


#7 jarazul

jarazul

    Board Veteran

  • 636 Beiträge

 

Geschrieben 08. Februar 2012 - 12:49

Das gilt nicht für AD RMS. Diese Daten sind über ein Public Key Verfahren verschlüsselt.

Der DRA Serviceaccount muss auch nicht von einem Admin abgebildet werden. Hochsensible Daten werden oft durch den Einsatz eines Kontos geschützt, das voraussetzt, dass zwei User notwendig sind für eine Authentifizierung / Authorisierung.

Es gibt genügend Unternehmen, die genau solche Anforderungen haben müssen und diese auch umsetzen. Diese vertrauen die ganz heiklen Daten auch keinem Admin an :)
MCTS: ConfigMgr 2007
MCITP EA / SA / EDA
ITIL v3 Foundation

#8 MrCocktail

MrCocktail

    Board Veteran

  • 1.214 Beiträge

 

Geschrieben 08. Februar 2012 - 18:52

Und glaube mir, wenn ich Admin bin, kann ich es lesen....
Der Aufwand dieses zu tun, geht vielleicht in die Hoehe, aber ich habe noch kein System gesehen, was einen Admin (ausser man riskiert den Verlust von Daten) wirklich aussperren kann.
Und ja, ich arbeite in einem Unternehmen, welches bestimmte Daten so ablegt, dass es erschwert ist, auf diese zuzugreifen und dieses auch zertifizieren lässt....

Aber ein Admin kann sich die Rechte verschaffen, welche er benötigt.

#9 jarazul

jarazul

    Board Veteran

  • 636 Beiträge

 

Geschrieben 08. Februar 2012 - 20:24

Kennst du das Thema AD RMS?
MCTS: ConfigMgr 2007
MCITP EA / SA / EDA
ITIL v3 Foundation

#10 Schmittchen

Schmittchen

    Newbie

  • 19 Beiträge

 

Geschrieben 08. Februar 2012 - 20:30

Sehr geehrte Damen und Herren hier an Board,

ich verfolge mit großem Interesse die Diskussion hier zum Thema "Daten schützen".

Desweiteren habe ich mich schon durch viele Seiten bezgl AD RMS gelesen aber eine Aussage konnte ich bisher nicht finden.

Wie ist der Account "Dienstkonto AD RMS" gegen Änderungen / Modifikationen des Admins geschützt ?

Es wäre sehr nett wenn ich hier eine Antwort erhalten könnte.

Mit freundlichen Grüßen
Schmittchen

#11 jarazul

jarazul

    Board Veteran

  • 636 Beiträge

 

Geschrieben 08. Februar 2012 - 20:38

Um das Service Konto zu ändern muss der USer Mitglied in den Gruppen:

AD RMS Organisationsadmins und der lokalen Admin Gruppe auf dem Server sein.

Changing the AD RMS Service Account

Auditing auf solch elementaren Gruppen sollte mit internen oder externen Tools angestrebt werden.

cheers, Daniel
MCTS: ConfigMgr 2007
MCITP EA / SA / EDA
ITIL v3 Foundation

#12 MrCocktail

MrCocktail

    Board Veteran

  • 1.214 Beiträge

 

Geschrieben 08. Februar 2012 - 20:49

@jarazul:
Grob, und ich kenne ein oder zwei theoretische Möglichkeiten es auszuhebeln, wie gesagt, wenn ich genügend Rechte habe, kann ich es aushebeln.
Kann ich mir Domänenadmin Rechte besorgen, kann ich auch den Service Account öffnen, es ist nur eine Frage von
- Zeit
- eingesetzten Ressourcen
- krimineller Energie

Und da alles weitere hier aus guten Gründen gegen Boardregeln verstösst, ist für diesen Teilaspekt für mich EOT.

#13 jarazul

jarazul

    Board Veteran

  • 636 Beiträge

 

Geschrieben 08. Februar 2012 - 20:58

Ich kann nur auf das FAQ von MS verweisen. Dort wird auf einige Fragen eingangen. U.a die Domain Admin Frage.

http://technet.micro...757(WS.10).aspxcheers und schönen Abend

Daniel
MCTS: ConfigMgr 2007
MCITP EA / SA / EDA
ITIL v3 Foundation

#14 MrCocktail

MrCocktail

    Board Veteran

  • 1.214 Beiträge

 

Geschrieben 08. Februar 2012 - 21:04

@jarazul:
und was steht da?

Is it possible for members of the Domain Admins group to read documents intended for someone in their domain?

Members of the Domain Admins group can read content protected to a user account if they are a member of the RMS super user group or if they are impersonating the user’s account. Because members of the Domain Admins group have control over the user accounts in the domain, there is no mitigation for the scenario of an untrustworthy member of the Domain Admins group.



#15 jarazul

jarazul

    Board Veteran

  • 636 Beiträge

 

Geschrieben 08. Februar 2012 - 21:10

Und was steht da weiter?

As with other groups used to limit access to resources, you should define alerts and perform security checks to help prevent someone from joining the super user group without authorization.


Wie wird denn in so einer High Tech Security Umgebung die Orga Admin oder Enterprise Admin Gruppe überwacht? Gar nicht? Weil jeder Domain Admin ist? Wofür wird der im täglichen Arbeiten gebraucht?

Sicherheit muss immer ganzheitlich betrachtet werden. Richtig implementiert kann mit AD RMS ein Dokumentenschutz gewährleistet werden der beim Vorhandensein von den üblichen Rahmenparametern (Rollenmodell, Auditing auf Orga, Schema, Enterprise Groups etc) dem gewöhnlichen Domänen Admin den Zugriff untersagt.
MCTS: ConfigMgr 2007
MCITP EA / SA / EDA
ITIL v3 Foundation