업데이트해서는 안되는 열에 대한 업데이트를 명시 적으로 거부해야합니까?

나는 매우 안전한 환경에서 일하는 데 익숙하므로 매우 세밀한 수준으로 내 권한을 디자인합니다. 내가 일반적으로하는 한 가지 일은 명시 적으로 DENY사용자 UPDATE가 업데이트해서는 안되는 열에 대한 기능을 명시 적으로 사용하는 것입니다.

예를 들면 다음과 같습니다.

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

값을 설정 한 후에는이 두 열을 절대로 변경해서는 안됩니다. 따라서 나는 분명히 그들에 DENY대한 UPDATE허가를 할 것입니다.

최근 한 팀 회의에서 개발자는 "어떤 이유로 값을 업데이트해야하는 경우"필드가 업데이트되지 않도록하는 논리가 데이터베이스 계층이 아니라 응용 프로그램 계층 내에 포함되어야한다는 점을 제기했습니다. 나에게 그것은 전형적인 개발자 정신과 같습니다 (나는 알고 있었지만, 나는 하나였습니다!)

저는 회사의 수석 설계자이며 항상 앱을 작동시키는 데 필요한 최소한의 권한 원칙에 따라 작업했습니다. 모든 권한은 정기적으로 감사됩니다.

이 시나리오에서 가장 좋은 방법은 무엇입니까?

논쟁은 이해가되지 않습니다. 항상 컨트롤과 제약 조건을 가능한 한 데이터에 가깝게 만들고 싶습니다. 응용 프로그램 계층에서 퍼팅 그것은 단지 사람에 영향을 의미합니다 사용하여 응용 프로그램 계층을하고, 또한 가정 의 코드가 버그가없는 것이라고 그 코드 경로에 보안이 방탄 될 것입니다. 그것들은 큰 가정입니다.

그들은 절대적으로 업데이트해야하는 경우, 그것은 명시 적으로 영향을받지 않는 사람에 의해 수행 될 수있다 DENY, 또는 사람이 일시적으로 영향을받지 않습니다 역할로 이동할 수 있습니다, 또는이 DENY일시적으로 제거 할 수 있습니다. 이들은 DBA로서 감사를 설정하기 쉬운 것들입니다. 앱에서? 별로.

기술적 인 측면에서 @Aaron에 전적으로 동의합니다.

모범 사례와 관련하여 내가 말할 것 외에도 :

1. 데이터를 보호하는 것이 DBA의 직무 / 책임임을 감안할 때 기본 접근 방식은 DBA가 적합하다고 판단하고 변경을위한 확실한 비즈니스 사례를 요구하는 것입니다. 가상의 미래 잠재력, 다소 가능성이있는 확실한 조건, 이후에 브레인 스토밍되고 나중에 확인 될 수 있지만, 이후에는 변경 될 수 있지만 나중에 변경 될 수도 있고 그렇지 않을 수도 있습니다. -실제로 일어날 수있는 이유 (즉, "어떤 이유로")는 특히 주제가 회사 표준 / 실습을 바꾸고있을 때 정당화에 약간 어렴풋한 것 같습니다.

2. 절대 바뀌지 말아야 할 것을 바꾸려고하는 사람을 절대로 신뢰하지 마십시오.

3. 개발자에게 이러한 업데이트를 방지하기 위해 이러한 논리를 앱 코드에 추가 할 수 있다고 알려주십시오. 그러나 또한를 제거하지 않을 것 DENY입니다. 하루가 올 때와그렇지 않을 수 있습니다아마) 그렇지 않을 것입니다 누군가 가이 열 중 하나를 업데이트하려고 시도하는 동안 오류가 발생하면를 제거할지 여부에 대한 토론 을 할 수 있습니다. DENY이는 누군가가 해당 값을 업데이트하는 이유에 대한 실제적이고 확실한 근거가 필요합니다. 처음.

   요점 : 사람들이 시간을 보내는 것에 대한 실질적인 비즈니스 사례가 있어야합니다. 시간은 수요가 많지만 공급이 부족하기 때문에 다른 사람의 의견에 따라 시스템을 변경하는 것보다 더 중요한 일이 있습니다. 항상 다양한 의견 (공백 대 탭, 누군가?)이있을 것입니다. 개발자가 떠나고 업데이트 할 수있는 분야에 강력히 반대하는 사람으로 대체되면 몇 년이 걸릴 수 있습니다. 고객이이를 요구하지 않거나 요구되는 것이없고, 실질적인 이익이없는 경우 (기술 부채 정리와 같은 지연된 이익조차도 ROI를 표시하기 어렵지만, 그 시간이 장기적으로 실제 비용 절감으로 이어지지 않을 가능성은 거의 없습니다), 그런 다음 이상주의가 변경되어야한다고 말하는 경우에도 요청을 닫거나 백 로그에 낮은 우선 순위로 두십시오 (이 경우 중 하나가 아니라 요청이라고 생각하는 사람들에 대해 언급 됨). 이상주의는 대화에는 적합하지만 기업은 임대료, 공공 요금, 직원, 세금 등을 이상적으로 지불 할 수 없습니다.

4. @ jpmc26은 의사 소통의 필요성에 대해서는 정확하지만 의사 소통이 필요한 것에 대해서는 정확하지 않습니다. 그렇습니다. 다른 사람이 요청한 내용을 듣고 자신의 추론을 이해하려고 노력해야합니다. 여기에는 무엇이든 확실하지 않은 경우 질문하는 것이 포함됩니다.

   그러나 데이터베이스는 응용 프로그램에 종속적이지 않으며 데이터베이스 전문가 (회사, 엔지니어, 회사 이름에 관계없이)는 개발자에게 종속적이지 않습니다 (해답에 암시 된 것처럼). 당신은 개발자를 위해 일하지 않고, 회사를 위해 일하는 것과 같이 일합니다. 이것은 팀의 노력이며, 일을한다고 용서하지 말아야합니다. 즉, 우리의 컴퓨터 유형은 인간 간 의사 소통 기술로 (일반적으로) 알려져 있지 않으므로 다른 사람들이 당신을 이해하고 , 당신의 추론이 무엇이며, 당신의 책임이 무엇인지, 그리고이 물건이 실제로 어떻게 작동하는지 확인해야합니다. .

   나는 마지막 부분에 오해, 잘못된 정보 및 지식 부족이 있기 때문에 (이 페이지의 일부조차도) 있기 때문에 마지막 부분에 넣었습니다. 예를 들어, 모든 규칙이 비즈니스 규칙이라는 개념이있는 것 같습니다. 우리는 데이터 규칙 및 비즈니스 규칙 (@Aaron는 질문에 단 댓글에서 "데이터 제한 대 워크 플로우 제약"으로이 함)에는 차이가 있다는 점을 설명해야 하고 대부분의 데이터가 자연스럽게 응용 프로그램에 속한 반면, 일부 데이터가 실제로 데이터 모델에 속합니다. DBA가 개발자에게 애플리케이션 데이터 를 제한 하는 방법을 지시해야합니까 ? 당연히 아니지. 응용 프로그램 데이터가 가능한 방법을 제공하는 것이 우리의 임무구속되다. 응용 프로그램 데이터와 관련된 비즈니스 규칙을 위반할 경우 피해를 입을 수 있고 앱이 데이터를 조작하는 100 % 유일한 방법 이 아닌 경우 검사 제한 조건이 실제로 도움이 될 수 있습니다 (변경 또는 제거가 어렵지 않음) ).

   그러나 다른 방향에서 오는 개발자는 데이터 모델 데이터 (예 : 메타 데이터)를 처리하는 방법을 지시해서는 안됩니다. 여기에는 감사 필드 (예 : created_on/ created_by열) 및 PK / FK 열이 포함됩니다 (이 값은 내부적으로 만 알려져 있으며 고객에게는 제공되지 않음). 이 데이터는 앱이 고객에 대해 저장하는 것이 아니라 (앱이 값을보고 ID와 같은 값을 사용할 수있는 경우에도) 데이터 모델이 앱의 데이터에 대해 저장하는 것입니다.

   따라서 데이터 규칙을 사용하여 데이터 모델 데이터를 보호하는 것이 좋습니다. 그리고 그렇게한다고해서 응용 프로그램 데이터에 제약 조건이나 제한을 추가하려고한다는 의미는 아닙니다. 그러나 이러한 차이를 이해하지 못하면 진정한 생산적인 방식으로 대화를 진행시키는 것이 어려울 것입니다.

그래서:

1. 예, DENY감사 열에 명시 적이 라는 아이디어 가 마음에 듭니다. 과거에도 일했던 곳에서도 같은 제안을했습니다.

2. 일화 적으로, 나는 외래 키를 추가하기 시작했을 때 2000 년에 수석 개발자 (아주 좋은 개발자)와 매우 비슷한 대화를 나 had습니다. 그는 불필요한 과도한 엔지니어링 / 이상주의 (그와 같은 대화는 17 년이 지났음)이며 성능에 대한 가치가 없다고 주장했습니다. 그는 관련 데이터 정리가 앱 계층에서 처리되어야한다는 것이 분명했습니다. (예, 코드가 필연적으로 생성되는 고아 데이터를 정리하는 사람이 아니기 때문에 FK를 추가했습니다)

   몇 년 후 그는 그 주장을 한 것에 대해 사과했다 ;-)

이것은 아마도 XY 문제 일 것입니다. 개발자는 특히와 같은 진정으로 일정한 필드의 업데이트를 차단하는 데 관심이 없을 것입니다 created_on. 이 특정 예는 매우 적당한 제약입니다.

개발자는 DBA 팀 (귀하를 포함)이 너무 많은 또는 복잡한 제한 사항을 추가하여 효과적으로 작업 할 수있는 능력을 저해하기 시작하거나, 평범하지 않은 일이 발생하거나 변경 될 때 DBA 팀이 변화에 저항하고 개발자 팀의 발전 능력을 방해 할 것입니다. 이것은 비교적 합리적인 관심사입니다. 관료주의와 필요한 변화에 영향을 줄 수있는 능력을 상실하는 것은 실제 발생이며, 너무 많거나 복잡한 제약 조건을 인코딩하면 성능과 요구 사항의 변화에 ​​대응하는 능력에 부정적인 영향을 줄 수 있습니다.

개발자는 이것이 자신의 우려의 본질임을 인식하지 못할 수도 있습니다. 그것들은 데이터베이스를 자유롭게 다스리는 데 익숙 할 것입니다. 특히 당신이 그것을 남용한 적이 없다는 것을 알고 있다면 그 수준의 자유를 포기하는 것은 어렵습니다. 따라서 필요한 것을 수행 할 수있는 능력을 상실하는 것에 대한 걱정은 모호하고 정의가 잘되지 않을 수 있습니다.

따라서 이러한 두려움을 해결하기 위해해야 ​​할 몇 가지 사항이 있습니다.

1. 개발자들과 많이 대화 하십시오. 이들이 구축하려는 기능의 요구 사항을 이해하고 변경 사항이 발생할 때 응답 성이 있는지 확인하십시오. 그들이하는 말에 귀를 기울이고 자신의 관심사와 자신의 문제를 균형있게 해결하는 방법을 찾기 위해 열심히 노력하십시오. 합법적 인 요구가있을 때 기꺼이 구부리십시오. 그들이 당신이 소프트웨어를 만드는 데 동맹 임을 알고 있는지 확인하십시오 .
2. 제한을 두는 것에주의하십시오. 완전성과 보안을 제공하기위한 제한조차도, 예측하지 못한 상황에 대처하거나 적응하기가 더 어려워 질 수 있습니다. 따라서 추가하는 각 제한은 비용을 절감 할 수있는만큼 비용이 절감 될 수 있다는 점을 이해하십시오 (거의 단점이없는 기본 및 외래 키는 제외). 부과 한 제한이 실제로 필요하거나 유익하다는 것을 확신하십시오.
3. 나는 당신이 이것을하고있는 어떤 징후도 보이지 않지만, 다른 독자들에게 그것을 언급하고 싶습니다 : 데이터 나 데이터베이스를 당신 이나 당신의 팀의 책임 으로 보지 마십시오 . 데이터는 회사 전체의 자산입니다. 시스템 (데이터베이스) 및 스크립트, 도구 또는 응용 프로그램을 생성, 업데이트 및 가져 오기 위한 시스템이 없으면 데이터가 가치가 없습니다. 모든 사람이이 자산을 사용해야하므로 데이터는 모든 사람의 책임입니다. 데이터베이스 자체는 데이터에서 가치를 얻는 것의 일부일뿐입니다.

상충되는 진술이 있습니다

• 절대 업데이트해서는 안되는 열
• 어떤 이유로 든 값을 업데이트해야합니다.

첫 번째 명령을 내리는 것은 정말로 당신에게 달려 있습니까?

앱이 값을 업데이트 할 필요가 없다는 증거없이 앱이 작동하게하려면 최소한 권한을 부여해야합니다.

데이터 무결성을 담당하는 사람은 누구입니까?

SQL 제약 조건으로 데이터 무결성을 보장 할 수 있습니까? 데이터베이스가 할 수있는 것 이상의 비즈니스 규칙이 있기 때문에 불가능합니다.

VendorID 는 변경되지 않아야 하지만 두 공급 업체가 병합되면 어떻게 됩니까 ? 절대 말하지 마

앱 팀이 데이터를 오염시키고 해당 권한이 필요하다고 말하면 데이터가 있습니다. 앱 팀이 당신을 위해 일한다면 당신은 지시 할 수 있습니다.

적절한 질문은 앱이 데이터를 업데이트해야하는 것입니다.