Sollte ich die Aktualisierung von Spalten, die nicht aktualisiert werden sollen, ausdrücklich verweigern?

Ich bin es gewohnt, in sehr sicheren Umgebungen zu arbeiten, und daher entwerfe ich meine Berechtigungen mit größter Genauigkeit. Eine Sache, die ich normalerweise mache, ist, den DENYBenutzern explizit die Möglichkeit zu geben, UPDATESpalten zu erstellen, die niemals aktualisiert werden sollten.

Beispielsweise:

create table dbo.something (
    created_by varchar(50) not null,
    created_on datetimeoffset not null
);

Diese beiden Spalten sollten nach dem Festlegen des Werts niemals mehr geändert werden. Deshalb würde ich ausdrücklich DENYdie UPDATEErlaubnis dazu geben.

Kürzlich hat ein Entwickler während eines Teammeetings darauf hingewiesen, dass die Logik zum Sicherstellen, dass die Felder niemals aktualisiert werden, in der Anwendungsschicht und nicht in der Datenbankschicht enthalten sein sollte, falls "die Werte aus irgendeinem Grund aktualisiert werden müssen". Für mich klingt das nach einer typischen Dev-Mentalität (ich weiß, ich war früher eine!)

Ich bin der leitende Architekt in meinem Unternehmen und habe immer nach dem Prinzip der geringsten Anzahl von Berechtigungen gearbeitet, die erforderlich sind, um die App zum Laufen zu bringen. Alle Berechtigungen werden regelmäßig überprüft.

Was ist die beste Vorgehensweise in diesem Szenario?

Das Argument ergibt keinen Sinn. Ich möchte immer, dass die Steuerelemente und Einschränkungen so nah wie möglich an den Daten sind. Um es in der Anwendungsschicht bedeutet , es betrifft nur die Menschen mit der Anwendungsschicht, und geht auch davon aus, dass der Code um diese Codepfade wird kugelsicher sein fehlerfrei und die Sicherheit sein. Das sind große Annahmen.

Wenn sie unbedingt aktualisiert werden müssen, kann dies von einer Person durchgeführt werden, die von dem Explizit nicht betroffen ist DENY, oder die Person kann vorübergehend in eine Rolle versetzt werden, die nicht betroffen ist, oder sie DENYkann vorübergehend entfernt werden. Dies sind Dinge, die für Sie als DBA leicht einzurichten sind. In der App? Nicht so viel.

Ich stimme @Aaron in Bezug auf den technischen Aspekt voll und ganz zu.

Darüber hinaus würde ich zu Best Practices sagen:

1. Da es die Aufgabe / Verantwortung des DBA ist, die Daten zu schützen, sollte der Standardansatz darin bestehen, genau das zu tun, wie es der DBA für richtig hält, und ein solides Geschäftsmodell für die Durchführung einer Änderung zu fordern. Ein hypothetisches Zukunftspotential, das unter bestimmten Bedingungen einigermaßen möglich ist, das später gedanklich erarbeitet und später bestätigt wird, aber vielleicht später oder vielleicht nie geändert wird -aktuell-geschehen Grund (dh "aus irgendeinem Grund") scheint eine rechtfertigungsschwache Angelegenheit zu sein, insbesondere wenn das Thema eine Unternehmensnorm / -praxis ändert.

2. Vertraue niemals jemandem, der Änderungen an etwas vornehmen möchte, das sich niemals ändern sollte ;-) (umso mehr, wenn er nicht einmal weiß, warum er dies möchte).

3. Teilen Sie dem Entwickler mit, dass er dem App-Code eine solche Logik hinzufügen kann, um diese Aktualisierungen zu verhindern. Aber auch, dass Sie das nicht entfernen werden DENY. Wenn / wann der Tag jemals kommt (und esmöglicherweise nichtWahrscheinlich wird nicht), dass jemand beim Versuch, eine dieser Spalten zu aktualisieren, eine Fehlermeldung erhält. Dann können Sie darüber diskutieren, ob Sie die entfernen DENY, was eine tatsächliche, solide Begründung erfordert, warum jemand diesen Wert in der aktualisieren würde erster Platz.

   Der springende Punkt: Es sollte einen echten Business Case geben, auf den sich die Menschen konzentrieren. Zeit ist gefragt, aber knapp, und Sie (und alle anderen) haben wichtigere Dinge zu tun, als das System auf der Grundlage der Meinung anderer zu ändern. Es wird immer eine Vielzahl von Meinungen geben (Leerzeichen oder Tabulatoren?), Und Sie könnten Jahre damit verbringen, dies hin und her zu ändern, wenn dieser Entwickler die Liste verlässt und durch einen ersetzt wird, der entschieden dagegen ist, dass diese Felder aktualisierbar sind. Wenn keine Kunden danach fragen (oder etwas, das dies erfordert) und es keinen greifbaren Vorteil gibt (sogar einen verspäteten Vorteil wie die Beseitigung von technischen Schulden, bei dem sich der ROI nur schwer belegen lässt, der sich jedoch angesichts der Tatsache lohnt, dass Die Chancen, dass diese Zeit nicht zu tatsächlichen Kosteneinsparungen auf lange Sicht führt, sind gering (oder gar nicht). Schließen Sie dann die Anforderung, oder stellen Sie sie mit einer niedrigen Priorität in den Rückstand, auch in Fällen, in denen der Idealismus eine Änderung vorsieht (dies ist nicht einer dieser Fälle, wird jedoch für diejenigen erwähnt, die dies für erforderlich halten). Idealismus ist ideal für Gespräche, aber Unternehmen können Miete, Nebenkosten, Angestellte, Steuern usw. nicht mit Idealen bezahlen.

4. @ jpmc26 ist in Bezug auf die Notwendigkeit der Kommunikation korrekt, aber nicht genau in Bezug auf die zu kommunizierenden Elemente. Ja, Sie sollten zuhören, was andere verlangen, und versuchen, ihre Argumentation zu verstehen, einschließlich Fragen zu stellen, wenn Sie sich über irgendetwas nicht sicher sind.

   JEDOCH ist die Datenbank der Anwendung nicht untergeordnet, und Datenbankprofis (Administratoren, Ingenieure, unabhängig vom Namen Ihres Unternehmens) sind den Entwicklern nicht untergeordnet (wie in dieser Antwort impliziert). Sie arbeiten nicht für die Entwickler, Sie arbeiten für das Unternehmen, genauso wie sie. Dies ist eine Teamleistung, und Sie sollten nicht um Vergebung bitten, wenn Sie Ihren Job machen. Das heißt, wir Computertypen sind (im Allgemeinen) nicht für unsere zwischenmenschlichen Kommunikationsfähigkeiten bekannt. Deshalb müssen Sie wirklich sicherstellen, dass andere Sie verstehen , wie Sie argumentieren, welche Verantwortlichkeiten Sie haben und wie diese Dinge tatsächlich funktionieren .

   Ich habe diesen letzten Teil eingefügt, weil es ein hohes Maß an Missverständnissen, Fehlinformationen und mangelndem Wissen gibt (sogar einige hier auf dieser Seite). Zum Beispiel scheint es diesen Gedanken zu geben, dass alle Regeln Geschäftsregeln sind. Wir müssen erklären, dass es einen Unterschied zwischen Datenregeln und Geschäftsregeln gibt (@Aaron bezeichnet dies in einem Kommentar zu der Frage als "Workflow-Einschränkung gegen Datenbeschränkung"), und dass die meisten Daten natürlich zur Anwendung gehören, einige Daten jedoch gehört eigentlich zum Datenmodell. Sollte ein DBA den Entwicklern vorschreiben, wie die Anwendungsdaten eingeschränkt werden sollen? Natürlich nicht. Es ist unsere Aufgabe zu opfern , wie die Anwendungsdaten könneneingeschränkt werden. Wenn ein Verstoß gegen eine Geschäftsregel in Bezug auf Anwendungsdaten Schaden anrichten kann und die App nicht die einzige Möglichkeit ist , die Daten zu manipulieren, hilft möglicherweise eine Einschränkung bei der Überprüfung (und es ist nicht schwierig, sie zu ändern oder zu entfernen) ).

   ABER aus der anderen Richtung kommend, sollten Entwickler nicht vorschreiben, wie Datenmodelldaten (dh Metadaten) behandelt werden. Dies schließt Prüffelder (wie die created_on/ created_bySpalten) und die PK / FK-Spalten ein (diese Werte sollten nur intern bekannt sein und nicht an Kunden weitergegeben werden). Diese Daten werden in der App nicht über Kunden gespeichert (auch wenn die App die Werte sehen und sogar verwenden kann, z. B. mit IDs), werden sie im Datenmodell über die Daten der App gespeichert.

   Daher ist es sinnvoll, Datenregeln zum Schutz von Datenmodelldaten zu verwenden. Dies bedeutet jedoch nicht, dass Sie mit dem Hinzufügen von Einschränkungen oder Restriktionen für die Anwendungsdaten beginnen. ABER es wird schwierig sein, das Gespräch wirklich produktiv voranzutreiben, wenn diese Unterscheidung nicht verstanden wird.

So:

1. Ja, ich mag die Idee des Expliziten DENYin den Prüfungssäulen und habe dasselbe auch an Orten vorgeschlagen, an denen ich in der Vergangenheit gearbeitet habe.

2. Anekdotischerweise hatte ich ein sehr ähnliches Gespräch mit einem leitenden Entwickler (einem sehr guten), vielleicht im Jahr 2000, als ich anfing, Fremdschlüssel hinzuzufügen. Er argumentierte (ziemlich ernsthaft), dass es unnötiges Über-Engineering / Idealismus war (so ähnlich, es sind 17 Jahre seit diesem Gespräch vergangen) und dass es den Leistungstreffer nicht wert war. Er war sich ziemlich sicher, dass die Bereinigung der zugehörigen Daten in der App-Ebene erfolgen sollte. (Ja, ich habe die FKs hinzugefügt, weil er nicht derjenige sein würde, der die verwaisten Daten bereinigt, die sein Code zwangsläufig erstellen würde.)

   Jahre später entschuldigte er sich dafür ;-)

Dies ist wahrscheinlich ein XY-Problem. Der Entwickler ist wahrscheinlich nicht besonders daran interessiert, Updates für ein wirklich konstantes Feld wie das zu blockieren created_on. Dieses besondere Beispiel ist eine äußerst bescheidene Einschränkung.

Der Entwickler ist wahrscheinlich besorgt darüber, dass das DBA-Team (zu dem auch Sie gehören) so viele oder so komplexe Einschränkungen hinzufügen möchte, dass die Fähigkeit, effektiv zu arbeiten, beeinträchtigt wird wird den Änderungen widerstehen und die Fähigkeit des Entwicklerteams behindern, Fortschritte zu erzielen. Dies ist ein relativ vernünftiges Anliegen. Bürokratie und der Verlust der Fähigkeit, die erforderlichen Änderungen zu bewirken, sind reale Ereignisse, und die Kodierung zu vieler oder komplexer Einschränkungen kann sich negativ auf die Leistung und die Fähigkeit auswirken, auf Änderungen der Anforderungen zu reagieren.

Der Entwickler kann nicht einmal erkennen, dass dies die Natur ihrer Bedenken ist. Sie sind es wahrscheinlich gewohnt, die Datenbank frei zu regieren, und es ist schwierig, dieses Maß an Freiheit aufzugeben, besonders wenn Sie wissen, dass Sie sie nie missbraucht haben. Ihre Besorgnis über den Verlust der Fähigkeit, das zu tun, was sie brauchen, könnte daher vage und unklar sein.

Es gibt also ein paar Dinge, die Sie tun sollten, um diese Befürchtungen zu zerstreuen:

1. Kommunizieren Sie intensiv mit den Entwicklern. Stellen Sie sicher, dass Sie die Anforderungen der Features verstehen, die sie erstellen möchten, und dass Sie auf Änderungen reagieren. Hören Sie sich an, was sie zu sagen haben, und arbeiten Sie hart daran, eine Lösung zu finden, die ihre Bedenken mit Ihren ausbalanciert. Sei bereit, dich zu beugen, wenn sie legitime Bedürfnisse haben. Stellen Sie sicher, dass sie wissen, dass Sie Verbündete beim Erstellen der Software sind.
2. Seien Sie vorsichtig, wenn Sie Beschränkungen einführen. Einschränkungen, auch solche, die Integrität und Sicherheit gewährleisten sollen, können die Anpassung an Änderungen oder den Umgang mit unvorhergesehenen Umständen erschweren. Verstehen Sie also, dass mit jeder von Ihnen hinzugefügten Einschränkung genauso wahrscheinlich Kosten verbunden sind wie Kosten gespart werden (mit der möglichen Ausnahme von Primär- und Fremdschlüsseln, die praktisch keine Nachteile haben). Seien Sie zuversichtlich, dass die von Ihnen auferlegten Einschränkungen wirklich erforderlich oder nützlich sind.
3. Ich sehe kein Zeichen, dass Sie dies tun, aber ich möchte es für andere Leser erwähnen: Sehen Sie die Daten oder die Datenbank nicht als Ihre oder die Verantwortung Ihres Teams an. Die Daten sind eine Bereicherung für das gesamte Unternehmen. Ohne ein System zum Speichern (der Datenbank) und Skripts, Tools oder Anwendungen zum Erstellen, Aktualisieren und Abrufen sind die Daten wertlos. Da jeder dieses Asset verwenden muss, liegt die Verantwortung für die Daten bei jedem. Die Datenbank selbst ist nur ein Teil des Erhalts von Werten aus den Daten.

Sie haben widersprüchliche Aussagen

• Spalten, die niemals aktualisiert werden sollten
• Sie müssen die Werte aus irgendeinem Grund aktualisieren

Ist es wirklich an Ihnen, das erste zu diktieren?

Sie haben das geringste Privileg, die App zum Laufen zu bringen, ohne zu beweisen, dass die App den Wert niemals aktualisieren muss.

Wer ist für die Datenintegrität verantwortlich?

Können Sie mit SQL-Einschränkungen die Datenintegrität gewährleisten? Nein, das können Sie nicht, da es häufig Geschäftsregeln gibt, die über das hinausgehen, was eine Datenbank leisten kann.

Die VendorID sollte sich niemals ändern, aber was passiert , wenn zwei Anbieter zusammengeführt werden ? Sag niemals nie.

Wenn das App-Team die Daten kontaminiert und angibt, diese Berechtigung zu benötigen, liegt dies an ihnen. Wenn die App-Teams für Sie arbeiten, können Sie diktieren.

Die passende Frage ist, ob die App jemals die Daten aktualisiert.