Berechtigungskonzept

Andi Fandrich Als Antwort am 11 Sept. 2013 16:39

Wie Du ja bereits selbst geschrieben hast, kann das hier niemand "mal eben so" beantworten. Woher sollte irgendjemand hier wissen, welche Berechtigungen Ihr Euren Benutzern geben wollt/sollt?

Aber eine Anmerkung zu

[quote user="Daniel M."]den Benutzern auf der produktiven Farm natürlich einige Rechte zu entziehen[/quote]

Ihr solltet in jedem Fall den Benutzern auf beiden Farmen identische Berechtigungen geben. Das führt sonst nur zu Verwirrung.

Daniel M. Als Antwort am 11 Sept. 2013 16:48

Hallo Andi,

wir wollen unseren Benutzern die Möglichkeit geben, auf der Testfarm auch mal rumzuexperimentieren, d.h. Seiten erstellen, Berechtigungen verwalten, usw... Auf der Produktivfarm hingegen soll z.b. die Vergabe von Rechten oder das Ändern / Löschen von bestehenden Seiten unterbunden werden, beziehungsweise erst nach erfolgreichen Tests von der IT erledigt werden. Daher tendiere ich eher zu unterschiedlichen Rechten..

Ich dachte nur, vielleicht kann jemand einige Erfahrungswerte über ein erfolgreich verwendetes Berechtigungskonzept geben..

Andi Fandrich Als Antwort am 11 Sept. 2013 17:06

[quote user="Daniel M."]wir wollen unseren Benutzern die Möglichkeit geben, auf der Testfarm auch mal rumzuexperimentieren[/quote]

Dagegen spricht natürlich nichts. Aber normalerweise hat man ja zumindest größere Anwendungen als Produktiv- und als Testversion und die sollten schon identisch aufgebaut sein.

Olaf Didszun Als Antwort am 11 Sept. 2013 22:20

Hi,

was Du vorhast klingt nach meinem Empfinden nicht nach einer Frage nach einem Berechtigungskonzept, sondern eher danach, welche Umgebungen ihr zur Verfügung stellen wollt oder müsst.

Euer Ausgangspunkt ist die Produktiv-Farm. Hier wird gearbeitet, hier werden die Daten aus der täglichen Arbeit gespeichert, diese Farm muss laufen.

Daneben und davon abgeleitet gibt es in den Begrifflichkeiten eine Test-Farm/Stage-Farm/QA-Farm/... Es gibt diverse Begriffe dafür, aber inhaltlich ist es ein Spiegelbild der Produktiv-Farm. Es sind dabei auch Umgebungen anzutreffen, in denen diese Test-Farm im Vergleich zur Produktiv-Farm reduziert wurde, was die Anzahl der Server oder die Ausstattung der Maschinen betrifft. Meist, um Ressourcen (und Geld) zu sparen. Hier finden u.a. die Tests statt, die notwendigerweise durchzuführen sind, wenn Patches eingespielt werden. Außerdem finden hier die User-Acceptance-Tests statt, wenn Anpassungen installiert werden sollen (dass passiert NICHT in der Produktiv-Farm). Deshalb ist diese Umgebung ein Abbild der Produktiv-Farm, also mit den gleichen Berechtigungen versehen. Wenn die Produktiv-Farm und die Test-Farm identisch aufgebaut sind, dann wird die Test-Farm auch gern dafür verwendet, um Performance-Tests durchzuführen.

Wenn eine Umgebung bereitgestellt werden soll, die wirklich nur zum ausprobieren, testen, kaputtmachen gedacht ist, dann sprechen wir üblicherweise von einer Sandbox. Hier sind häufig die Solutions und Anwendungen ebenfalls installiert, die auch in der Produktiv- oder Test-Umgebung anzutreffen sind, aber die weiteren Einstellungen können sehr wohl abweichen. Das ist auch der hauptsächliche Grund, weshalb eine solche Sandbox erstellt wird, nämlich eine Umgebung zu haben, die bewusst abweichend angelegt ist, damit auch mal etwas schiefgehen kann. In größeren Unternehmen wird der Aufbau einer Sandbox daher meist auch weitestgehend automatisiert (z.B. mit Microsoft System Center), sodass bei Bedarf relativ schnell eine saubere Umgebung erstellt werden kann. Snapshots in virtualisierten Umgebungen können hier ebenfalls ein gutes Hilfsmittel sein, um schnell eine Sandbox zur Verfügung zu stellen.

Ich hoffe, das hilft Dir etwas weiter.

Grüße

Olaf

Peter Oswald Als Antwort am 12 Sept. 2013 07:40

[quote user="Daniel M."]auch eine Testfarm zu installieren und dann den Benutzern auf der produktiven Farm natürlich einige Rechte zu entziehen[/quote]

Dieses Szenario kenne ich so nicht. Was sollte das auch bringen, eine Testfarm anzulegen, auf der die Berechtigungen dann anders sind? Das bringt die Benutzer nur durcheinander. Entweder so, wie es Olaf gerade beschrieben hat oder man richtet eine separate Website-Collection ein mit eigener Content-Database auf der die Benutzer dann tun und lassen können was sie wollen. Geht's schief, dann wandert nur die Collection ins Recycling und nicht gleich ne ganze Farm.

Florian Adler Als Antwort am 12 Sept. 2013 10:25

Abgesehen von der Kritik an den Berechtigungsunterschieden zwischen Test und Produktiv ist erst einmal zu klären, an welche Informationen welcher MItarbeiter in welcher Form rankommen darf.

Wir hatten neulich einen Kunden, bei dem wir zunächst die Informationsstruktur definieren mussten. Damit wird auch klar, welche Informationen wie zu schützen sind. Daraus ergeben sich letztlich auch die Berechtigungen.

Ist man dann noch so crazy drauf und will das automatisiert laufen lassen, sind natürlich auch Anpassungen am AD ratsam und im Zuge  dessen die Kompilierung von Benutzergruppen.

Daniel M. Als Antwort am 3 Dez. 2013 12:00

Hallo Leute,

danke erstmal für eure Antworten. Das Thema ist jetzt wieder aktuell und ich denke, dass ich hier noch etwas präzisieren muss:
Wir hatten uns gedacht, dass die Key-User auf der Testfarm alles machen können (Seiten erstellen, berechtigen, usw).
Um einen "Wildwuchs" auf der Produktivfarm zu vermeiden, haben wir uns überlegt diesen Usern auf der Produktivfarm nur mehr die Mitwirken, bzw. Designrechte zu geben, damit wir dann entscheiden können, ob die Änderungen Sinn machen und die Governance respektieren und diese dann entweder auf die Produktivfarm übertragen oder verwerfen (weil Käse :-)).
Das gleiche gilt auch für die Rechtevergabe: Einige Mitarbeiter sind SEHR freizügig mit der Vergabe von Rechten und auch hier braucht es ein Kontrollorgan, d.h. die definitiven Rechte auf der Prod-Farm würden auch nur wir pflegen. Dies würde dann nur die KeyUser (oder PowerUser) betreffen, die 'normalen' Benutzer hätten natürlich auf beiden Farmen die gleichen Rechte.

Wir wollen da nichts automatisiert laufen lassen.

Danke nochmal