Generell:
Ist die Anwendung produktspezifisch an
SQL Server gebunden, kann man am ehesten mit
OS Usern / Trusted Login arbeiten. Ansonsten gar nicht erst mit Trusted Login loslegen, sondern standardmäßig mit
SQL user.*
Wann/Was
Datenhaltung (plus ggF. Logik) im
SQL Server per
SQL User (nenne ich immer Application Owner)
Das ist nicht zu verwechseln mit irgendwelchen Systemaccounts.
Eine Anwendung sollte
DB seitig m.E. niemals im Kontext eines Standard Admin Kontos laufen.
Der Nutzerzugriff durch die Anwender kann dann per
Trusted Login erfolgen**, besonders wenn eh im Windows Domänen Kontext gearbeitet wird. Auch diese Nutzer können mit unterschiedlichen Rechten/Rollen verwendet werden, idealerweise weniger Rechte als der Application Owner.
Gibt es keine Windows Domäne, entfällt Nutzen und Einsatzmöglichkeit des Trusted Logins mehr oder weniger.
Wird Trusted Login eingesetzt, empfiehlt sich allerdings dann auf Domänenebene, entsprechende Rechtegruppen zu definieren, Projekt spezifisch oder fachlich, damit nicht jede Putzkraft einloggen kann. (Obwohl, die sind ja meist extern heutzutage)
* Oder auf allgemein verfügbare singlesignon Verfahren setzen
**Das ist wirklich bequem, bedeutet allerdings auch, dass eine fehlende Abmeldung in der Kaffepause von jedem genutzt werden kann, an der Anwendung rumzuspielen.