Обмежити оновлення для певних стовпців. Дозволити збережену процедуру оновлювати ці стовпці


17

У мене є чутливі стовпці цін, які я хотів би оновити лише через збережену процедуру. Я хотів би, щоб усі кодові чи ручні спроби зміни значень у цих цінових стовпцях вийшли з ладу, якщо він не використовує збережені процедури, призначені для його оновлення.

Я розглядаю можливість здійснення цього за допомогою тригерів та таблиці лексем. Я розглядаю ідею - мати таблицю лексем. збережені процедури повинні спочатку вставити значення в таблицю токенів. Потім оновіть стовпці цін. Тригер оновлення перевірить, чи існує маркер у таблиці лексем для оновленого рядка. Якщо його знайдуть, це продовжиться. якщо маркер не знайдений, він викине виняток і призведе до помилки транзакції оновлення.

Чи існує хороший / кращий спосіб здійснити це обмеження?


1
Ви можете використовувати подання для захисту на основі стовпців. Це буде набагато елегантніше, ніж тригер. Надати користувачам дозвіл на перегляд, але не основні дані.
Томас Стрінгер

Це хороший момент. Але проблема залишається невирішеною, не порушуючи безліч додатків, які використовують об'єднання з'єднань.
Ілля

Чи можете ви пояснити, яким чином це буде "розбиттям багатьох програм, які використовують об'єднання з'єднань"?
Аарон Бертран

Відповіді:


21

SQL Server дозволяє дозволи на рівні стовпців. Просто для прикладу:

GRANT UPDATE ON dbo.Person (FirstName, LastName) TO SampleRole;
DENY UPDATE ON dbo.Person (Age, Salary) TO SampleRole;

Дякую Міхалу, але це рішення не допоможе мені, тому що моя програма - це веб-додаток, який використовує об'єднання з'єднань. Усі користувачі підключаються за допомогою однієї і тієї ж лінії підключення SQL Server.
Ілля

1
@Elias я не розумію. Рядок з'єднання підключається як конкретний користувач, правда? Тож замініть SampleRoleцього користувача ...
Аарон Бертран

Дозволи на рівні стовпців - це спосіб перейти сюди. Це і гарантувати, що розробники знають, що внесення змін до значень через t-sql безпосередньо знищить систему.
mrdenny

6
-- prevent your web app user from updating that column directly:

DENY UPDATE ON dbo.YourTable(Price) TO WebApplicationUserName;
GO

-- create a stored procedure while logged in as sysadmin:

CREATE PROCEDURE dbo.UpdateYourTable
  @ProductID INT,
  @Price DECIMAL(10,2)
WITH EXECUTE AS OWNER
AS
BEGIN
  SET NOCOUNT ON;

  UPDATE dbo.YourTable 
    SET Price = @Price
    WHERE ProductID = @ProductID;
END
GO

-- grant explicit access only to that stored procedure to the web app user:

GRANT EXEC ON dbo.UpdateYourTable TO WebApplicationUserName;

2

Якщо всі ваші користувачі мають однаковий логін (ouch, BTW), тут є ще один варіант

  • відкликати права оновлення у цього користувача (або ролі, якщо ви робите це таким чином).
  • Змініть збережену програму із застереженням "виконувати як власника"
  • тоді збережена програма виконуватиметься з правами користувача, якому належить схема, в якій вона перебуває (якщо вона є dbo, то ви вже охоплені).

У постійних користувачів додатків бракує прав на оновлення цієї таблиці, тому вони не зможуть оновити її іншим способом.


Вам не потрібно створювати нового користувача, щоб це зробити ...
Аарон Бертран

@aaronbertrand ви маєте рацію - так, e reasonni думав, що ви зробите "виконати як творця", але це не річ - ви можете "виконати як власника" до тих пір, поки користувач, який володіє схемою, мав права на оновіть цю таблицю. Якщо збережене програмне забезпечення знаходиться у dbo, ви закриваєтеся. Я оновлю свою відповідь.
SqlRyan
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.