Une invite n’est pas un système d’autorisation
Il est tentant d’ajouter « afficher uniquement mon territoire » à l’invite du système et de passer à autre chose. Je comprends l’appel. Mais une invite est une suggestion, et le modèle peut l’ignorer, l’oublier ou la mal interpréter sur une question difficile. Une meilleure configuration analyse le SQL généré et le réécrit avant que quoi que ce soit ne s’exécute, de sorte que les règles résident dans le code que le modèle ne peut pas contourner. Dans le benchmark derrière ce travail, la solution la plus courante sur 900 requêtes de test consistait à ajouter un filtre de ligne au WHERE clause (285 fois). Le masquage des colonnes est venu ensuite (240), suivi de la restriction de la portée (165).
Oui ou non est rarement la vraie réponse
La plupart des vraies questions ne correspondent pas parfaitement à l’autorisation ou au refus. Sur les mêmes 900 requêtes, 40 % pourraient s’exécuter sans modification. 20 % supplémentaires avaient besoin d’un filtre de lignes, 15 % d’un masquage de colonnes et 11,7 % d’une réécriture de jointure. Environ 6,7 % ont été adressés à un évaluateur humain et 6,7 % supplémentaires ont été bloqués. La plupart des gens ont quand même obtenu une réponse utile. C’était simplement plus sûr, et je pense que le commerce est la bonne chose à faire.
Vérifiez avant son exécution et gardez le compte petit
Validez chaque requête avant son exécution. Rejeter SELECT *des extractions qui dépassent les limites de la portée, des ensembles de résultats surdimensionnés et des jointures risquées. Envoyez ensuite le tout via une passerelle qui se connecte à un compte de base de données restreint. De cette façon, une injection rapide ou une mauvaise génération ne peuvent pas contourner vos règles, même lorsque le modèle fait preuve de créativité.
