Для додатків бази даних часто необхідно, щоб доступ до базових таблиць і об'єктів в схемі додатка здійснювався за допомогою процедур або уявлень початкового рівня. Це необхідно, щоб кінцевим користувачам можна було надати доступ до об'єктів початкового рівня, які зможуть звертатися до базових об'єктів від імені користувача. Таким чином, немає необхідності надавати кінцевим користувачам доступ до всіх об'єктів в схемі додатка. Такий підхід переслідує дві мети.
- Він спрощує управління дозволами тим, що це управління виконується тільки на невеликому підмножині об'єктів, а не на всіх об'єктах схеми програми.
- Від користувача можна приховати макет основний схеми, так як йому надаються тільки точки входу.
Для підпису даних формується зведення даних, проводиться шифрування цієї зведення за допомогою відкритого ключа та прикріплення зашифрованого стисненого значення до даних. Щоб перевірити підпис, перевіряючий використовує закритий ключ власника підпису для розшифровки прикріпленого до даних зашифрованого стисненого значення. Потім перевіряючий порівнює розшифроване стислий значення зі стисненим значенням, обчисленим на супутніх даних. Важливо, щоб і власник підпису, і перевіряючий для стиснення даних використовували одну і ту ж хеш-функцію.
Підписання модулів повинно використовуватися тільки для надання дозволів, і ніколи - для заборони або скасування дозволів.
Припустимо, доступ до подання sys.sysprocesses повинен здійснюватися за допомогою процедури, що usp_sysprocesses. Користувачі можуть звертатися до даних уявлення sys.sysprocesses тільки через процедуру usp_sysprocesses. Так як об'єкти usp_sysprocesses і sys.sysprocesses мають різних власників, ланцюжки володіння неспроможні.
Спочатку на сервері з пари ключів повинен бути створений сертифікат за допомогою інструкції CREATE CERTIFICATE. Далі сертифікату надаються дозволи для вибору з таблиці sys.sysprocesses. Але, оскільки сервер SQL Server надає дозволи тільки учасникам, необхідно спочатку за допомогою інструкції CREATE LOGIN з сертифіката створити ім'я входу. Цьому імені входу не потрібні на сервері дозволу на підключення, так як воно є тільки местозаполнітелем дозволів і не призначений для підключення до примірника сервера. Цьому імені входу, пов'язаному з сертифікатом, потім можна надати дозвіл SELECT для таблиці sys.sysprocesses за допомогою інструкції GRANT VIEW SERVER STATE TO. Після створення збереженої процедури usp_sysprocesses ця процедура, що зберігається може бути підписана за допомогою сертифіката (в дійсності - закритим ключем, відповідним до сертифіката) в інструкції ADD SIGNATURE. Створюється нова роль, якої надаються дозволи на виконання збереженої процедури usp_sysprocesses. В результаті користувачі, які є членами цієї ролі, отримують дозвіл виконувати збережену процедуру usp_sysprocesses і, отже, дозвіл SELECT на вибір з уявлення sys.sysprocess. При виконанні підписаного модуля ті дозволи, які надані учаснику (за допомогою інструкції GRANT) і пов'язані з сертифікатом підписання, оператором UNION тимчасово вбудовуються в маркер безпеки на час виконання виклику. Після повернення управління виконання ці дозволи видаляються з маркера безпеки. Таким чином, додатковий набір дозволів існує тільки під час виконання модуля. Будь-який інший користувач або інша роль, яким надано дозволи EXECUTE на цю процедуру, будуть мати такі ж можливості.