О паролях в регулируемых системах фармпроизводства

То, что компьютеры и компьютеризированные системы (КС) сейчас используются повсеместно, даже в самых захудалых компаниях, думаю, ни у кого не вызывает сомнений. Но если компания относится к регулируемым, то вопросы безопасности её КС стоят на первом месте. Думаю, что из названия статьи уже ясно, о чем мы будем говорить. Да, да, о паролях. Вход в систему по логину и паролю – это самый простой и быстрый способ ограничения доступа к системе.С логином (или учетной записью пользователя) все понятно – это неизменный атрибут. Пользователь получает уникальный логин при первом допуске к системе и отдает его при запрете доступа к этой системе, например, при переходе в другой отдел, где эта система не используется, или при увольнении. А вот по поводу пароля некоторое время назад возник вопрос: как часто надо менять этот самый пароль и какие требования к его сложности? Как думаете?

Некоторые утверждают, что каждые три месяца, другие, что каждые шесть месяцев, а еще есть вариант менять каждый месяц. Где же золотая середина и как часто надо выполнять эту операцию?

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

Как вы уже догадались, общая концепция периодичности смены пароля заключается в снижении риска компрометации конкретной системы, то есть неконтролируемого доступа к ней и управления ею. Фактически, в сравнении с другими средствами контроля доступа, ограничение доступа по паролю является относительно слабой защитой (на мой взгляд, наиболее слабое звено в этой защите – это пользователь).

Для какой-то системы пароль, возможно, и вовсе не требуется периодически менять, для какой-то смена каждые 3 или 6 месяцев будет достаточной, а для систем, которые являются критическими для качества, безопасности и эффективности продукта или же от их правильной работы зависит жизнь человека, пароль потребуется менять каждые 30 дней или чаще.

Например, в руководстве NIST SP 800-63B-3, которое рекомендую к ознакомлению, указано:

Do not require that memorized secrets be changed arbitrarily (e.g., periodically) unless there is a user request or evidence of authenticator compromise.

То есть, не требуется произвольно (периодически) менять пароли, за исключением непосредственной просьбы пользователя или доказательства компрометации аутентификатора.

В рекомендациях Microsoft указано, что пароль может быть скомпрометирован на нескольких базовых этапах, а именно, при назначении, выдаче пользователям, управлении и использовании. Поэтому рекомендуется предпринять следующие предупредительные меры:

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

В ПО Windows Server период смены пароля по-умолчанию составляет 42 дня и может быть изменен в диапазоне от 0 (без смены) до 999 дней. Если существует угроза безопасности, то рекомендуемыми периодами смены пароля являются 30, 60 и 90 дней, если такая угроза низкая, то 120, 150 и 180 дней.

В целом, любая современная серверная ОС имеет развитые средства управления паролями на сетевых машинах пользователей.

Как видно из информации выше, в ИТ среде существует достаточное количество рекомендаций (как частных вендоров, так и международных и государственных организаций) касательно периодичности смены паролей и требований к их сложности.

Более детально можете ознакомиться с руководствами ITSM, ISACA и ISO.

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

А как на счет того, чтобы не менять пароль вообще или как можно реже?

Опять же, все зависит от выполненной оценки рисков. Но в пользу не слишком частой смены пароля для не слишком критичных систем есть и ряд вполне здравых доводов. Например, почитайте эту или эту статью.

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

  • e%~9]>W7
  • i#>w]=(_
  • PBR>eEhD

Непросто. Верно? Хотя у кого-то зрительная память может быть и уникальной. И это пароль длиной 8 символов с латинскими буквами разного регистра, цифрами и спецсимволами. Думаю, что среднестатистический пользователь после 10 повторений запомнит. А теперь заставим такого пользователя менять такой пароль на подобный и запоминать его каждые 30, 60 или даже 90 дней. Понятно, что рано или поздно этот процесс вызовет у него «батхерт» и он начнет либо забывать пароль, либо путаться в них, либо записывать на бумажках, в телефоне, на руке, спинке стула, днище своей любимой чашки для кофе 🙂 и т.д.

То есть, необходимо продумать и это условие – как при учете требований к сложности пароля и периодичности смены не заставить пользователя записывать его где-то, а хранить только в своей голове?

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

  • при первом входе в систему нового пользователя, он должен использовать базовый пароль, например, выданный администратором или сгенерированный системой и показанный ему;
  • сразу после входа в систему, до доступа пользователя к её функциональным элементам, он должен сменить базовый пароль на свой собственный в соответствии с требованиями к сложности паролям, установленными в организации;
    • требования должны быть знакомы пользователю, и по возможности описаны в форме смены пароля;
    • требования могут включать следующие базовые элементы:
      • длина не менее 8 символов;
      • латинские буквы верхнего регистра;
      • латинские буквы нижнего регистра;
      • спецсимволы (например, !@#$%^&);
      • как минимум три символа должны быть из предыдущих трех пунктов;
      • пароль не должен содержать имени пользователя (учетной записи) и не должен быть эквивалентным ему (ей);
      • пароль не должен быть словом или фразой, которое можно найти в обычном словаре;
      • пароль не должен быть типичной шаблонной клавиатурной комбинацией (например, qwerty);
      • пароль не должен основывать на персональных данных пользователя (например, день рождения, адрес, имя и т.п.);
      • пароль не должен совпадать с использованными ранее паролями;
      • пароль должен отличаться от предыдущего как минимум на 3 символа;
      • опционально – пароль не должен повторяться для конкретного пользователя, для этого должна вестись история паролей, хранимых в зашифрованной форме;
    • перечисленные выше требования являются достаточно жесткими и мне кажется, что неплохим вариантом, который облегчил бы жизнь пользователя, могло бы быть допущение использования пароля в виде фраз значительной длины, в которых слова содержат хотя бы одну букву другого регистра, одну цифру и разделены комбинациями спецсимволов. Если вы хотя бы раз пробовали взломать пароль методом «атаки по словарю» или «прямым перебором возможных комбинаций» при использовании достаточно надежного алгоритма шифрования пароля, то знаете, что при длине от 10 символов подбирать пароль можно целую вечность, ну а про подбор такой фразы длиной даже 20 символов можно только мечтать. Хотя можно попросить майнеров биткоина расшифровать пароль, за биткоины естественно 🙂
  • пользователь не должен нигде записывать и хранить пароль (от слова вообще!). Только в своей голове;
  • пароль рекомендуется менять не реже каждых 6 месяцев для пользовательских машин и не реже 3 месяцев для серверов (или на основании вашей оценки рисков);
  • пароль запрещено передавать какими-либо незашифрованными средствами коммуникации, в том числе по телефону, email и т.д.;
  • пользователи должны использовать разные пароли для систем, которые не поддерживают единую авторизацию;
  • пользователь не должен передавать пароль другим сотрудникам, независимо от их должности, администраторам и сотрудникам ИТ-отдела. Пароль должен знать только сам пользователь. Важно понимать, что у администратора и так монопольный доступ высшего уровня, поэтому ему нет нужды знать пользовательский пароль.
  • опция запоминания пароля для входа в систему должна быть отключена;
  • опция автоматического входа в систему также должна быть отключена;
  • пароль в системе должен храниться в зашифрованном виде, а алгоритм шифрования должен быть односторонним и устойчивым к взлому, для критических систем алгоритм не должен иметь коллизий;
  • пользователь должен иметь возможность самостоятельной смены пароля в любое время при подозрении на его компрометацию.

Если я что-то упустил по списку выше и у вас есть соображения по этому поводу, тогда велкам в комментарии 🙂

В заключение

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

Подписывайтесь на каналы PHARM COMMUNITY:

   
Поделитесь с коллегами:

4 коментарі до “О паролях в регулируемых системах фармпроизводства”

  1. Статья замечательная.

    В Индустрии есть чувство, что IT опасности где то в кино и в новостях.

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

    • Андрей, спасибо за отзыв!

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

      Ну и еще такой фактор, как что либо вовремя поправить, подкорректировать, чтобы проверка не прицепилась к непонятным результатам :).

  2. Антон, спасибо за статью.

    Хотелось бы добавить то, что использование пароля в виде фразы или словосочетания может удовлетворять требованиям к надежности. Для этого достаточно придумать фразу на кириллице, содержащую буквы (х, ъ, ж, э, б, ю), но вводить ее в английской раскладке. Такой пароль является достаточно надежным и легким для запоминания. Справедливости ради, нужно отметить, что такой вариант имеет место быть только с клавиатурами (экранными или физическими), которые имеют одновременное отображение двух раскладок на клавишах.

    • APV, это отличный вариант создания сложного пароля. Спасибо, что дополнили! Сам таким пользуюсь иногда, в частности, для почтовых ящиков. Хотя вы правильно заметили, что клавиатура должна обязательно иметь обе раскладки. Плюс это специфично для тех регионов, где другой алфавит, отличный от английского и не стоит забывать, что такой пароль в какой-то степени попадает под правило не использовать словарных слов, то есть как минимум это должна быть нестандартная фраза, незнакомая окружающим и никак не характеризующая вас.

Залишити коментар до APV Скасувати коментар