Здравствуйте!

Имеется программный комплекс, реализованный следующим образом:
- СУБД - MS SQL 2008;
- бизнес-логика реализована в виде Java EE приложения, исполняющегося под управлением JBoss Application Server;
- доступ к БД реализован посредством системы объектно-реляционной проекции Java Persistence API (точнее, ее реализацией - Hibernate);
- Java EE приложение и СУБД расположены во внутренней сети, доступ к СУБД разрешен исключительно для этого приложения;
- запросы к Java EE приложению проходят через межсетевой экран;
- пользователи комплекса работают с ним, авторизуясь на основе системы ролей.

Указанный доступ к БД через Java Persistence API реализован НЕ посредством хранимых процедур. То есть непосредственно в коде Java EE приложения нет явным образом выполняемых SQL-запросов, однако, уровень Java Persistence API выполняет преобразование объектной модели в SQL-запросы (SELECT, UPDATE и так далее).

Правильно ли я понимаю, что такое исполнение доступа к БД нарушает пункт 8.5.16 стандарта?

Спасибо!

Добрый вечер.

Если используется аутентификация в СУБД для доступа Java EE приложения, то нарушения 8.5.16а нет.
Если под логином Java EE приложения, кроме самого приложения, еще работают пользователи, то нарушается процедура 8.5.16b.

Здравствуйте!

На мой взгляд, описанное решение всё-таки нарушает требование 8.5.16.a.

Требование об использовании программных методов относится к БД и подразумевает наличие в БД защищенного интерфейса для её пользователей (в т. ч. приложений), например в виде хранимых процедур. При использовании Hibernate всё равно остается открытым прямой доступ к данным со стороны Hibernate, эта сущность не является неотъемлемой частью БД, соответственно является внешней по отношению к БД, в то же время она не используется пользователем с правами DBA, а значит имеет место нарушение части 3 требования 8.5.16.a: «Direct access or queries to databases are restricted to database administrators».

При этом сохраняется риск инъекций, подробнее об этом написано на сайте проекта OWASP (англ): http://www.owasp.org/index.php/Interpreter_Injection#ORM_Injection

При невозможности использования хранимых процедур я бы предложил рассмотреть варианты компенсирующих мер (compensating controls).

Требование 8.5.16:
Authenticate all access to any database containing cardholder data. This includes access by applications, administrators, and all other users.

Риск, на снижение которого направлена реализация требования (intent):
Without user authentication for access to databases and applications, the potential for unauthorized or malicious access increases, and such access cannot be logged since the user has not been authenticated and is therefore not known to the system. Also, database access should be granted through programmatic methods only (for example, through stored procedures), rather than via direct access to the database by end users (except for DBAs, who can have direct access to the database for their administrative duties).

Процедуры аудита для проверки степени выполнения этого требования:
8.5.16.a Review database and application configuration settings and verify that user authentication and access to databases includes the following:
• All users are authenticated prior to access.
• All user access to, user queries of, and user actions on (for example, move, copy, delete), the database are through programmatic methods only (for example, through stored procedures).
• Direct access or queries to databases are restricted to database administrators.
8.5.16.b Review database applications and the related application IDs to verify that application IDs can only be used by the applications (and not by individual users or other processes).

А теперь обобщаем все это кратко по-русски:
Чтобы снизить потенциальную опасность от неавторизованного доступа к данным платежных карт, хранящимся в СУБД, необходимо гарантировать, что
1) все субъекты доступа аутентифицируются при получении доступа к СУБД
2) возможность выполнения произвольных запросов к базе данных дана только тем людям, кому без этого не жить (то есть нельзя заранее описать конечное множество необходимых им для работы запросов к СУБД), а все остальные забывают про селекты и имеют возможность выполнения только задуманного для них функционала приложения, который доступен им через интерфейс этого приложения.
3) технологические учетные записи, необходимые для работы приложения и имеющие обычно привилегированные права, не раздаются людям или другим процессам для удобства доступа к СУБД (это реально очень удобно: раздать права владельца схемы и не мучиться над подбором минимально достаточного набора прав для реализации какой-то задачи). Соответственно люди используют свои персональные учетные записи, а «левые» процессы-специально под них выделенные, чтобы по логам можно было определить, кто именно имел доступ и к чему.

При описанной Андреем реализации приложения нарушений по 8.5.16.а нет, так все пользователи аутентифицируются в приложении и ни один из них не имеет возможность выполнения прямых запросов к СУБД (легитимный доступ реализован через логику приложения и, так как, по-видимому, для каждого пользователя создается учетная запись в СУБД, то сетевой доступ к СУБД закрыт, чтобы пользователи не имели возможности подключаться иначе как через приложение.)
Для оценки 8.5.16b информации нет, а 8.5.16.а , повторюсь,не нарушается никоим образом.

Теперь что касается рисков использования инъекций. Как говорит мой босс, «давайте отделять мухи от котлет», то есть при оценке ситуации не мешать все в кучу. Подход «мне что-то в описанной реализации не нравится, правда точно не знаю, какое требование здесь не выполняется, но чувствую что риск есть» не очень подходит для compliance-аудита. Анализ безопасности приложения, в частности web-приложения, должен проводиться либо в рамках аудита по PCI DSS по пунктам 6.3, 6.5 (в случае если используемое приложение написано в стенах проверяемой организации или под его заказную разработку), либо в рамках сертификации приложения по стандарту PA-DSS (для коробочных решений). В рамках указанных проверок и будет оценена возможность эксплуатации популярных веб-уязвимостей (по OWASP) в данном приложении, а также наличие в процессе его разработки и поддержки контрольных процедур, гарантирующих невозможность появления подобных уязвимостей при его развитии в будущем. В случае, если во внутренней сети используется заказная разработка, пока не сертифицированная по PA-DSS, в безопасности которой Вы не уверены, мы настоятельно РЕКОМЕНДУЕМ провести независимый анализ ее безопасности и принять необходимые меры в случае, если буду выявлены уязвимости. Только вот к PCI DSS 8.5.16 это уже не относится 

Прошу прощения за нудное объяснение.