Часто приходится сталкиваться с неправильной интерпретацией требований 8.1, 8.5.8 и 8.5.16.b стандарта PCI DSS и адресуемых ими рисков:

• «в стандарте написано, что нельзя использовать групповые идентификаторы для выполнения административных задач и других критичных функций, но наши пользователи не имеют полномочий на изменение данных, а значит можно под одной учетной записью работать»;
• «в стандарте написано идентификаторы пользователей, а к администраторам систем эти требования не относятся»;
• «в стандарте написано, что нельзя использовать встроенные идентификаторы, то есть нельзя пользоваться учетной записью oracle или root». Как следствие, непонимание сути требования приводит к неправильной его реализации.

Вот несколько примеров типичных ситуаций несоответствующих требованиям Стандарта:

• сотрудники дежурной службы (мониторинг, call-center) используют групповые учетные записи;
• администраторы повсеместно используют привилегированные учетные записи (root, oracle, administrator) для любого доступа к системе;
• пароли привилегированных учетных записей известны большому количеству сотрудников;
• нет разделения на технологические учетные записи, используемые приложениями (скриптами автоматизации) и пользовательские, используемые людьми.

Использование групповых учетных записей так же может приводить к нарушению еще ряда требований Стандарта - по периодической смене паролей и блокированию учетных записей после исчерпания лимита попыток неправильного вода пароля, так как данные настройки, обычно, отключают для групповых учетных записей.

Суть данных требований Стандарта в том, что должна быть обеспечена отслеживаемость любого доступа (в том числе и на чтение) к данным платежных карт, а так же все действия, предпринимаемые индивидуальными пользователями, включая сотрудников с административными полномочиями.

Когда под одной учетной записью в систему могут входить несколько пользователей, не существует способа определить, кто именно из них что и когда делал. Если же привилегированная учетная запись доступна целой группе администраторов, то вы и понятия не будете иметь о том, кто ею пользуется и что он при этом делает, а если такой доступ был несанкционированным и системе был нанесен ущерб, вы не сможете идентифицировать нарушителя.

Назначение уникального идентификатора каждому пользователю позволяет поддерживать индивидуальную ответственность сотрудников за свои действия и однозначно отслеживать все действия, выполняемые каждым сотрудником.

Выполнить данные требования можно следующим образом:

• создать персонифицированные учетные записи для всех категорий пользователей, включая администраторов (рекомендуется сделать это, даже если сервером управляет один человек);
• запретить техническими мерами удаленную регистрацию в системе под технологическими и привилегированными системными учетными записями (например, root, oracle);
• операторам/администраторам, выполняющим специальные задачи (например, создание резервных копий) кому нет необходимости в неограниченных привилегиях в системе, предоставить минимально необходимые права для выполнения конкретных административных операций без возможности свободно работать в системе (например, использовать механизм sudo/setuid, а настоящий пароль суперпользователя будут знать всего один-два человека);
• при необходимости выполнения задач, требующих полномочий системных и технологических учетных записей, обеспечить процесс аутентификации таким образом, чтобы необходимо было сначала зарегистрироваться в системе под персональной учетной записью, а затем переключиться на привилегированную учетную запись (например, использовать su).