Я бы из третьей таблицы убрал поле rigth (зачем собственно оно нужно? есть запись — есть доступ, нет записи — нету доступа) и ID, и оставил составной ключ из пользователя и группы (тогда избежишь лишних проверок на совпадение данных).

Еще для себя иногда я делал битовое поле в таблице объектов для указания общих вседоступных объектов. Правда потом отказался это делать — большого смысла в такой идеологии нет.

Еще — по алгоритму. При создании пользователя или группы необходимо давать минимальные права . При создании модуля, прав никому не давать . Тогда избежишь многих ошибок с доступами. Мало-ли как будет — создал ты модуль или пользователя, отвлекся, и забыл про него. А права у него максимальные. Пользователь с минимальными правами к тебе тут-же прибежит, и это отследить можно. Пользователь-же с максимальными правами ничего не заметит, а проблемы потом возникнуть могут.
Для отображения списка ролей я использовал обычный repeater, при щелчке на роль проваливался в такой-же repiter, но уже со списком ролей и с checkbox'ами, отмеченными в соответствии с правами.

ЗF>При изменении прав предполагается выполнять соответствующее число команд INSERT или можно как-то вставить данные за один запрос (MSSQL 2000)?
Я делал через один. Тут надо балансировать. С одной стороны — в 2к нет параметризированного списка — т.е. когда в in передаешь параметр. Соответственно надо слеплять запрос, а этот путь может привести к хаку, через запросы. С другой стороны делать кучу инсертов — как-то неудобно... В принципе можно обойтись хранимкой, которая принимает на вход массив прав, и ты уже лепишь запрос в хранимке.