Ограничение количества записей, разрешенных в таблице, способом, который нельзя подорвать - PullRequest
Новая
       28

Ограничение количества записей, разрешенных в таблице, способом, который нельзя подорвать

2 голосов
/ 15 апреля 2011

У нас есть веб-приложение (Grails), для которого мы собираемся продавать лицензии в зависимости от количества пользователей.В базе данных есть таблица (Oracle 10g), которая содержит пользователей.Клиенты будут размещать свои собственные копии программного обеспечения и базы данных.Может ли кто-то предложить стратегии для ограничения количества записей, которые могут существовать в пользовательской таблице таким образом, чтобы клиент не мог их разумно подорвать?Спасибо.

Ответы [ 3 ]

5 голосов
/ 15 апреля 2011

Вы должны, по крайней мере, рассмотреть возможность избежать всех технических средств здесь и вместо этого настаивать на том, чтобы ваш клиент подписал SLSA с предоставлением аудита, а затем проводить аудит здесь и там.

Все эти технические средства вводят риски отказа, начинаяот плоских сбоев до таинственных проблем с производительностью.Чем более скрытны и коварны, тем более скрытны и коварны ошибки.

4 голосов
/ 15 апреля 2011

Это будет зависеть от вашего определения «разумно».Если они размещают базу данных, они всегда смогут разрешить большее количество строк.

  • Самое простое возможное решение - триггер AFTER STATEMENT, который подсчитал количество строк и вывел исключение, если тожемного строк было вставлено.Конечно, они могут сбросить или отключить этот триггер.С другой стороны, ваше приложение может также запросить словарь данных, чтобы убедиться, что триггер присутствовал и был включен.
  • Для них было бы сложнее удалить триггер, создав триггер DDL, который искал операторы.это повлияло на этот триггер или соответствующую таблицу и запретило их.Для этого потребуется, чтобы злоумышленник также нашел и удалил этот триггер, прежде чем он сможет удалить триггер на столе.
  • Вы могли бы доставить задание базы данных (DBMS_SCHEDULER или DBMS_JOB), которое периодически запускалось, искало операторы и триггеры DDL и заново создавало их, если они отсутствовали.Злоумышленник может выяснить, что существует задание базы данных, воссоздающее объекты, и удалить это задание, затем удалить триггер DDL, а затем удалить триггер оператора.В этой работе вы могли бы потенциально отправить вам обратно уведомление (по электронной почте или через http или что-то еще), предупреждающее вас о проблеме, хотя это может быть сложно с точки зрения сети - брандмауэр вашего клиента может не разрешать исходящие HTTP-запросы из базы данных.сервер обратно к вашим серверам.
  • Если у вас проверяется лицензионный ключ, вы можете встроить количество пользователей, разрешенных в этом лицензионном ключе, и отразить его в соответствии с количеством строк в таблице во время таблицы входа в систему.,
0 голосов
/ 18 апреля 2011

Если у клиента нет доступа для изменения определения таблицы, вы можете использовать простой набор ограничений для таблицы: 

CREATE TABLE user_table
(id   NUMBER PRIMARY KEY
,name VARCHAR2(100) NOT NULL
,rn   NUMBER NOT NULL
,CONSTRAINT rn_check CHECK (rn = TRUNC(rn) AND rn BETWEEN 1 AND 30)
,CONSTRAINT rn_uk    UNIQUE (rn)
);

Теперь столбец rn должен принимать целочисленное значение от 1 до 30, и дубликаты не допускаются: таким образом, можно добавить максимум 30 строк.

...