Введите пароль: обзор форм авторизации и альтернативных способов идентификации пользователей — Офтоп на

Введите пароль: обзор форм авторизации и альтернативных способов идентификации пользователей — Офтоп на Сертификаты

Авторизация с помощью клиентских ssl сертификатов. – itc-life

Протокол безопасной передачи данных SSL (Secure Sockets Layer) помимо
обеспечения безопасной передачи данных позволяет также реализовать
авторизацию клиентов на сервере с помощью клиентских SSL сертификатов.
Данная статья является практическим руководством по реализации данного
вида авторизации. В статье не рассматриваются теоретические основы
криптографии или передачи данных по протоколу SSL. Подразумеваемся,
что читатель хотя бы поверхностно знаком с понятиями, используемыми в
этой статье, такими как сертификат, секретный ключ, подпись
сертификата и т.д.

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

Наиболее наглядным примером использования авторизации посредством
клиентских сертификатов является система платежей WebMoney Transfer, а
точнее реализация WM Keeper Light. Данная схема авторизации признана
наиболее надежной и, в том или ином виде, широко используется в сфере
предоставления банковских услуг.

Практическая реализация рассматривается на основе популярной связки
веб-сервера Apache (https://httpd.apache.org/) и модуля mod_ssl (https://www.modssl.org/),
основанного на использовании библиотеки openssl (https://www.openssl.org/).
Предполагается, что соответствующее программное обеспечение у вас уже
установлено.

Для реализации процесса авторизации по клиентским сертификатам
требуется:

1. Создать собственный доверенный сертификат (Certificate Authority),
для того чтобы с помощью него подписывать и проверять клиентские
сертификаты.
2. Создать клиентские сертификаты, подписанные доверенным
сертификатом, для последующей передачи их клиентам.
3. Сконфигурировать веб-сервер для запроса и проверки клиентских
сертификатов.

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

Создание собственного самоподписанного доверенного сертификата.

Собственный доверенный сертификат (Certificate Authority – далее CA)
необходим для подписи клиентских сертификатов и для их проверки при
авторизации клиента веб-сервером. С помощью приведенной ниже команды
создается закрытый ключ и самоподписанный сертификат.

# openssl req -new -newkey rsa:1024 -nodes -keyout ca.key -x509 -days 500 
-subj /C=RU/ST=Msk/L=Msk/O=My Inc/OU=Sale/CN=bla/emailAddress=usr@dom.ru 
-out ca.crt

Описание аргументов:

req

Запрос на создание нового сертификата.

-new

Создание запроса на сертификат (Certificate Signing Request –
далее CSR).

-newkey rsa:1023

Автоматически будет создан новый закрытый RSA ключ длиной 1024
бита. Длину ключа можете настроить по своему усмотрению.

-nodes
Не шифровать закрытый ключ (См. примечание выше).
-keyout ca.key
Закрытый ключ сохранить в файл ca.key.
-x509
Вместо создания CSR (см. опцию -new) создать самоподписанный
сертификат.
-days 500

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

-subj /C=RU/ST=Msk/L=Msk/O=My
Inc/OU=Sale/CN=bla/emailAddress=usr@dom.ru

Данные сертификата, пары параметр=значение, перечисляются через
‘/’. Символы в значении параметра могут быть “подсечены” с
помощью обратного слэша “”, например “O=My Inc”. Также можно
взять значение аргумента в кавычки, например, -subj
“/xx/xx/xx”.
Описание параметров:
С – Двухсимвольный код страны (Country). Необязательный
параметр.
ST – Название региона/области/края/республики/… (State
Name). Необязательный параметр.
L – Название города/поселка/… (Locality Name).
Необязательный параметр.
O – Название организации (Organization Name).
Необязательный параметр.
OU – Название отдела (Organization Unit). Необязательный
параметр.
CN – Имя сертификата, при создании серверных сертификатов
используется доменное имя сайта, для клиентских
сертификатов может быть использовано что угодно (Common
Name). Обязательный параметр. Максимальная длина 64
символа.
emailAddress – почтовый адрес (E-mail address).
Необязательный параметр. Максимальная длина 40 символов.

Необязательные параметры могут быть пропущены, например,
/C=RU/CN=blabla/emailAddress=user@domain.ru.

-out ca.crt
Сертификат сохранить в файл ca.crt.

В результате выполнения команды появятся два файла ca.key и ca.crt.

Просмотреть данные закрытого ключа и сертификата вы можете с помощью
команд:

# openssl rsa -noout -text -in ca.key (для ключа)
# openssl x509 -noout -text -in ca.crt (для сертификата)

Создание клиентских сертификатов

Подготовка конфигурации и файлов для подписи сертификатов.

Создайте конфигурационный файл с именем ca.config следующего
содержания.

[ ca ]
default_ca = CA_CLIENT # При подписи сертификатов
# использовать секцию CA_CLIENT
[ CA_CLIENT ]
dir = ./db # Каталог для служебных файлов
certs = $dir/certs # Каталог для сертификатов
new_certs_dir = $dir/newcerts # Каталог для новых сертификатов
database = $dir/index.txt # Файл с базой данных
# подписанных сертификатов
serial = $dir/serial # Файл содержащий серийный номер
# сертификата
# (в шестнадцатиричном формате)
certificate = ./ca.crt # Файл сертификата CA
private_key = ./ca.key # Файл закрытого ключа CA
default_days = 365 # Срок действия подписываемого
# сертификата
default_crl_days = 7 # Срок действия CRL (см. $4)
default_md = md5 # Алгоритм подписи
policy = policy_anything # Название секции с описанием
# политики в отношении данных
# сертификата
[ policy_anything ]
countryName = optional # Код страны - не обязателен
stateOrProvinceName = optional # ......
localityName = optional # ......
organizationName = optional # ......
organizationalUnitName = optional # ......
commonName = supplied # ...... - обязателен
emailAddress = optional # ......

Создайте структуру каталогов и файлов, соответсвующую описанной в
конфигурационном файле

# mkdir db
# mkdir db/certs
# mkdir db/newcerts
# touch db/index.txt
# echo "01" > db/serial

Примечание: В файле db/serial записывается текущий серийный номер
подписываемого сертификата в шестнадцатиричном формате. В файл
db/index.txt сохраняются данные о подписываемых сертификатах.

Создание клиентского закрытого ключа и запроса на сертификат (CSR).

Для создания подписанного клиентского сертификата предварительно
необходимо создать запрос на сертификат, для его последующей подписи.
Аргументы команды полностью аналогичны аргументам использовавшимся при
создании самоподписанного доверенного сертификата (см. $1), но
отсутсвует параметр -x509.

# openssl req -new -newkey rsa:1024 -nodes -keyout client01.key 
-subj /C=RU/ST=Msk/L=Msk/O=Inc/OU=Web/CN=usr/emailAddress=usr@dm.ru 
-out client01.csr

В результате выполнения команды появятся два файла client01.key и
client01.csr. Просмотреть данные закрытого ключа и запроса на
сертификат (CSR) вы можете с помощью команд:

# openssl rsa -noout -text -in client01.key (для ключа)
# openssl req -noout -text -in client01.csr (для запроса)

Подпись запроса на сертификат (CSR) с помощью доверенного сертификата (CA).

При подписи запроса используются параметры заданные в файле ca.config

# openssl ca -config ca.config -in client01.csr -out client01.crt -batch

Описание аргументов:

ca

Подпись запроса с помощью CA.

-config ca.config

Использовать конфигурационный файл ca.config.

-in client01.csr

CSR находится в файле client01.csr

-out client01.crt

Сохранить сертификат в файл client01.crt

-batch

Не спрашивать подтверждения подписи.

В результате выполнения команды появится файл клиентского сертификата
client01.crt. Просмотреть данные сертификата вы можете с помощью
команды:

# openssl x509 -noout -text -in client01.crt

Подготовка данных для передачи клиенту.

Для передачи полученных в результате предыдущих операций файлов
клиенту, обычно используется файл в формате PKCS#12. В этот файл
упаковывается и защищается паролем вся информация необходимая клиенту
для инсталяции сертификата в броузер.

# openssl pkcs12 -export -in client01.crt -inkey client01.key 
-certfile ca.crt -out client01.p12 -passout pass:q1w2e3

Описание аргументов:

pkcs12

Работа с файлами формата PKCS#12.

-export

Экспортирование данных в файл.

-in client01.crt

Файл клиентского сертификата.

-inkey client01.key

Файл закрытого ключа.

-certfile ca.crt

Файл доверенного сертификата.

-out client01.p12

Сохранить данные в файл client01.p12.

-passout pass:q1w2e3

Установить пароль q1w2e3 на файл (пароль может быть любым, в
том числе и пустым)

Про сертификаты:  Международная сертификация MS Office Specialist - как подготовиться и получить сертификат

На этом процесс создания клиентского сертификата завершен. Теперь вам
необходимо передать клиенту файл client01.p12 и пароль к нему любым
удобным безопасным способом, а также проинструктировать его о
процедуре инсталяции сертификата в броузер.

Для создания новых клиентских сертификатов повторите операции с $2.2.
по $2.4.

Настройка веб-сервера.

Для реализации процесса авторизации по клиентским сертификатам
необходимо сконфигурировать веб-сервер для решения следующих задач:
1. Запрет доступа к защищаемой области по протоколу HTTP.
2. Запрос и проверка клиентских сертификатов.

Запрет доступа к защищаемой области по протоколу HTTP.

Найдите в конфигурационном файле веб-сервера httpd.conf секцию
, соответсвующую вашему сайту и добавьте в неё
следующие директивы

SSLRequire

Описание директив:

/path/to/secure/area/

Абсолютный путь до директории защищаемой области.

SSLRequire

Запрещает доступ клиенту, если при соединении не используется
протокол HTTPS (HTTP через SSL).

Запрос и проверка клиентских сертификатов.

Найдите в конфигурационном файле веб-сервера httpd.conf секцию ,
соответсвующую вашему сайту и добавьте в неё следующие директивы:

SSLCACertificateFile /path/to/ca.crt
SSLVerifyClient require

Описание директив:

SSLCACertificateFile /path/to/ca.crt

Абсолютный путь до доверенного сертификата (см. $1.). Также в
качестве значения директивы SSLCACertificateFile может быть
указан файл, содержащий несколько доверенных сертификатов
(формируется путем обычной конкатенации файлов сертификатов),
тогда все они будут считаться доверенными сертификатами.

SSLVerifyClient require

При наличии этой директивы веб-сервер будет запрашивать
сертификат у клиента в обязательном порядке. Если клиент не
предоставляет сертификат, тогда сервер отклоняет запрос. Если
клиент предоставляет сертификат, то веб-сервер проверяет его
срок действия и поставщика сертификата (сертификат которым он
подписан), если сертификат поставщика присутсвует в файле
SSLCACertificateFile, то проверка считается успешной и клиенту
предоставляется доступ до защищенной области.

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

# apachectl restart

Альтернативные способы настройки веб-сервера.

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

Пример 1.

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

SSLVerifyClient require
SSLRequire %{SSL_CLIENT_I_DN_O} eq "First CA Inc."

Описание директив:

SSLRequire %{SSL_CLIENT_I_DN_O} eq "First CA Inc."

Требует чтобы организацией поставщика клиентского сертификата
являлась “First CA Inc.”. Аналогичным способом можно проверять
любые другие параметры клиентского сертификата или его
поставщика. Более подробную информацию о директиве SSLRequire и
именах переменных смотрите в документации по mod_ssl.

Пример 2.

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

SSLVerifyClient require
SSLOptions  FakeBasicAuth
AuthName "My secure area"
AuthType Basic
AuthUserFile /path/to/passwd/file
require valid-user

Содержимое файла /path/to/passwd/file

/C=RU/L=Msk/O=My Inc./CN=user/emailAddress=user@domain.ru:xxj31ZMTZzkVA
/C=RU/L=Sam/O=My LTD./CN=vas/emailAddress=vas@domain.ru:xxj31ZMTZzkVA
/C=RU/L=Zel/O=My LLC./CN=prs/emailAddress=prs@domain.ru:xxj31ZMTZzkVA
........

Описание директив:

SSLOptions  FakeBasicAuth

Имитирует простую авторизацию веб-сервером. Имя пользователя и
пароль не запрашиваются, но сверяются данные клиентского
сертификата с данными в файле /path/to/passwd/file. Строка
идентифицирующая клиента может быть получена из клиентского
сертификата с помощью команды:

# openssl x509 -noout -subject -in client.crt

Или взята из базы данных db/index.txt, формируемой при подписи
CSR (см. $2.). В качестве пароля всегда используется строка
“xxj31ZMTZzkVA”, являющаяся результатом шифрования строки
“password” с помощью алгоритма DES.

Отзыв сертификатов.

Результат проверки веб-сервером клиентского сертификата будет успешным
на весь срок действия сертификата. Возникает вопрос, что делать в
случае если вы хотите отказать какому-либо клиенту в доступе по его
клиентскому сертификату. Для решения этой проблемы создается список
отзыва сертификатов (Certificate Revocation List – CRL). В списке
отзыва перечисляются отозванные вами клиентские сертификаты. В
соответсвии с этим списком веб-сервер будет отклонять запросы если
сертифкат клиента отозван.

Создание списка отзыва (CRL).

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

# openssl ca -gencrl -config ca.config -out ca.crl

Описание аргументов:

ca

При создании CRL также используется этот аргумент.

-gencrl

Создание списка отзыва сертификатов.

-config ca.config

Использовать конфигурационный файл ca.config.

-out ca.crl

Сохранить созданный список отзыва в файл ca.crl

В результате будет создан список отзыва, основанный на базе данных
подписанных сертификатах db/index.txt. Так как на данный момент ни
один из сертификатов в базе данных не помечен как отозванный, то
созданный список будет пустым. Просмотреть данные списка отзыва вы
можете с помощью следующей команды.

# openssl crl -in ca.crl -text -noout

Одной из важных черт списка отзыва является его срок действия,
указываемый в конфигурационном файле ca.config с помощью директивы
default_crl_days. Также альтернативно может быть использована
директива default_crl_hours, если вы планируете часто обновлять ваш
CRL. Список отзыва должен обновляться не позже истечения срока
действия. Для переодического вызова приведенной выше команды можно
использовать cron.

Отзыв сертификата.

Для того чтобы отозвать клиентский сертификат необходимо пометить его
в базе данных сертификатов db/index.txt как отозванный, тогда при
следующем обновлении списка отзыва, этот сертификат будет в него
включен. Для пометки сертификата как отозванного используйте
приведенную ниже команду.

# openssl ca -config ca.config -revoke client01.crt

Описание аргументов:

-revoke client01.crt
Отозвать сертификат находящийся в файле client01.crt

Настройка веб-сервера

После создания списка отзыва сертификатов необходимо дать возможность
веб-серверу использовать его. Для этого добавьте приведенную ниже
директиву в конфигурационный файл веб-сервера.

SSLCARevocationFile /path/to/ca.crl

Описание директив:

SSLCARevocationFile /path/to/ca.crl
Абсолютный путь до файла со списком отзыва сертификатов (см.
$4.1.)

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

# apachectl restart

Заключение.

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

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

open ( LOCK, ">/tmp/cert-sign.lck" ) or error_handling();
flock ( LOCK, 2 ) or error_handling();

# … код, реализующий подпись сертификата …

close( LOCK );

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

Про сертификаты:  Яхтинг в Москве

Второй совет связан с извлечением и обработкой данных клиентских
сертификатов в CGI-скриптах. При простой авторизации клиента по имени
и паролю веб-сервер помещает имя пользователя в переменную окружения
REMOTE_USER. Аналогичным образом из переменных окружения можно извлечь
данные клиентского сертификата при авторизации по сертификату. Для
того чтобы веб-сервер устанавливал значения переменных окружения,
относящихся к клиентскому сертификату необходимо добавить в
конфигурацию веб-сервера следующую директиву:

SSLOptions  StdEnvVars  ExportCertData

Описание директив:

 StdEnvVars
Включает установку в переменные окружения данных, относящихся к
SSL.
 ExportCertData

Включает установку в переменные окружения текста сертификатов
использовавшихся при передаче данных.

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

Альтернативой переменной REMOTE_USER могут служить следующие
переменные: SSL_CLIENT_M_SERIAL - серийный номер клиентского
сертификата, SSL_CLIENT_S_DN_CN - имя сертификата (Common Name) или
SSL_CLIENT_S_DN - данные сертификата (Subject Name, см. описание
аргумента -subj в $1). Если вы хотите использовать переменную
SSL_CLIENT_S_DN_CN для идентификации пользователя, то вы должны
обеспечить уникальность Common Name для разных сертификатов при
создании запросов на клиентский сертификат (см. $2.2.). Уникальность
SSL_CLIENT_M_SERIAL и SSL_CLIENT_S_DN гарантируется автоматически при
подписи сертификатов.

Несколько мелких замечаний от Александр Елисеенко:

1) ключ -sabj при генерации сертификатов явно лишний, все именные
данные и так будут запрошены (в интерактиве). Для упрощения жизни
можно отредактировать файл openssl.cnf, секция [
req_distinguished_name ]. Тогда останется только жать ENTER.

2) специально создавать файл ca.config нет смысла, дешевле
воспользоваться готовым openssl.cnf

3) подробное освещение вопроса генерации сертификатов - дело нужное,
но не лишним было бы отметить, что в составе дистрибутива openssl есть
готовый скрипт CA (CA.sh или GA.pl), с помощью которого ключи
генерятся без всяких проблем

(https://www.opennet.ru/tips/info/681.shtml)

Ну и по вопросу организации проверки клиентских сертификатов на
сервере - не все так просто,как написано в статье.

Корневой (или доверенный) сертификат может быть не один. Каталог, где
они размещены, указывается директивой SSLCACertificatePath. Для
каждого доверенного сертификата должен быть указан md5 hash. Все
доверенные сертификаты могут быть сгруппированы в один файл (вместе с
md5 хэшем, а не путем обычной конкатенации файлов сертификатов), путь
к нему в этом случае указывается директивой SSLCACertificateFile. Если
используются довереннные сертификаты, подписанные другими CA, то
директивой SSLVerifyDepth устанавливается глубина проверки цепочки
сертификатов.

Разъяснения о сертификации по приказу министерства здравоохранения от 14.04.2020 №327н

Свежие новости о разъяснении по сертификации согласно Приказу Министерства Здравоохранения от 14.04.2020 №327н

До недавнего времени профессиональное сообщество, эксперты и юристы расходились во мнении, что же значит «мораторий на выдачу сертификатов в 2020 г.». Было 2 основные точки зрения, как трактовать эту формулировку:

  1. Право на отсрочку получения сертификата. Физическим лицам предоставлено право воспользоваться отсрочкой в необходимости получения сертификатов специалистов до 01.01.2021 г. При этом никаких ограничений по прохождению обучения, при желании, а равно по выдаче сертификатов образовательными учреждениями не установлено.
  2. Установлен полный запрет на выдачу сертификатов учебными заведениями до конца 2020г, что автоматически подводит медиков к обязательной аккредитации в 2021году (приказ 1043Н с 01.01.2021 отменяет выдачу сертификатов, а приказ 327н не разрешает их выдавать до 01.01.2021)

На днях в интернете появилось разъяснение Минздрава от зам. министра Семеновой Т.В.

«Пунктом 2 приказа № 327н устанавливается мораторий на срок до 1 января 2021 г. на получение сертификатов специалиста и свидетельств об аккредитации специалиста, в том числе лицами, прошедшими аккредитацию специалиста. Таким образом, в срок до 1 января 2021 г. проведение процедур аккредитации специалистов и сертификационного экзамена (включая подачу заявления и документов для прохождения указанных процедур, рассмотрение поданных документов, прохождение указанных процедур специалистами, проведение заседаний соответствующих комиссий и подкомиссий) нецелесообразно в связи с тем, что выдача свидетельств об аккредитации специалиста и сертификатов специалиста по итогам проведения данных процедур осуществляться не будет, а возможность осуществления профессиональной деятельности без указанных документов установлена пунктом 1 приложения к приказу № 327н.»

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

В связи с этим у большинства специалистов возникают вопросы:

  1. Есть ли возможность зачислиться в последний набор на курсы повышения квалификации с выдачей сертификата?
  2. Что делать тем, у кого сертификат специалиста истек раньше 6 апреля и на кого продление срока действия сертификата не распространяется?
  3. Необходимо ли проходить курсы повышения квалификации в 2020 году без получения сертификата не реже одного раза в 5 лет в течение всей трудовой деятельности, согласно требованиям приказов 707н и 83н ?
  4. Кому необходимо проходить 36 часовые краткосрочные курсы повышения квалификации?
  5. Пройдя профессиональную переподготовку в 2020 году, можно ли работать по данной специальности не имея свидетельства об аккредитации?

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

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

Что мы предлагаем:

  • Повышение квалификации и переподготовку по всем медицинским специальностям
  • 36 баллов НМО ежегодно(дистанционно) помощь в регистрации на портале
  • Информационная рассылка для наших подписчиков о мероприятиях на 14 баллов, набираемых путем участия в вебинарах, тестированиях и конференциях.
  • Помощь в прохождении последующей аккредитации.
  • Личного менеджера, круглосуточную поддержку и бесплатную консультацию, полное сопровождение Вашей организации.

Нам доверяют обучение: «INVITRO», «МЕДСИ», «Euromed», «лаборатория Гемотест», «СМ – клиника», «РЖД – медицина», «МНТК им. Федорова», «ФГБОУ ВО РНИМУ им. Н.И. Пирогова», «КБ управление делами Президента», «Семейный доктор» и многие другие.

Министерство здравоохранения Российской Федерации в связи с
многочисленными обращениями по вопросам применения приказа Минздрава России
от 14 апреля 2020 г. № 327н «Об особенностях допуска физических лиц к
осуществлению медицинской деятельности и (или) фармацевтической деятельности
без сертификата специалиста или свидетельства об аккредитации специалиста и (или)
по специальностям, не предусмотренным сертификатом специалиста или
свидетельством об аккредитации специалиста» сообщает следующее.
В связи с угрозой распространения новой коронавирусной инфекции
COVID-19 принят Федеральный закон от 1 апреля 2020 г. № 98-ФЗ «О внесении
изменений в отдельные законодательные акты Российской Федерации по вопросам
предупреждения и ликвидации чрезвычайных ситуаций» (далее – Федеральный закон
№ 98-ФЗ).
В рамках полномочий, установленных подпунктом «д» пункта 2 части 1 статьи
17 Федерального закона № 98-ФЗ Правительством Российской Федерации издано
постановление от 3 апреля 2020 г. № 440 «О продлении действия разрешений и иных
особенностях в отношении разрешительной деятельности в 2020 году» (далее –
постановление № 440).
Согласно пункту 2 приложения № 9 постановления № 440 Минздравом России
утвержден приказ от 14 апреля 2020 г. № 327н, в соответствии с которым вводится
мораторий на получение свидетельств об аккредитации специалиста и (или)
сертификатов специалиста, продлевается срок действия сертификатов специалиста на
12 месяцев, а также определяются случаи и условия, при которых допуск физических
лиц к осуществлению медицинской или фармацевтической деятельности возможен
без наличия указанных документов.
В части разъяснения положений приказа № 327н поясняем следующее.
1. Пунктом 2 приказа № 327н устанавливается мораторий на срок
до 1 января 2021 г. на получение сертификатов специалиста и свидетельств об
аккредитации специалиста, в том числе лицами, прошедшими аккредитацию
специалиста.
Таким образом, в срок до 1 января 2021 г. проведение процедур аккредитации
специалистов и сертификационного экзамена (включая подачу заявления и
документов для прохождения указанных процедур, рассмотрение поданных
документов, прохождение указанных процедур специалистами, проведение
заседаний соответствующих комиссий и подкомиссий) нецелесообразно в связи с
тем, что выдача свидетельств об аккредитации специалиста и сертификатов
специалиста по итогам проведения данных процедур осуществляться не будет, а
возможность осуществления профессиональной деятельности без указанных
документов установлена пунктом 1 приложения к приказу № 327н.
Лицам, прошедшим аккредитацию специалиста до вступления в силу приказа
№ 327н (т.е. до 25 апреля 2020 г. включительно) и не получившим свидетельство об
аккредитации специалиста, такое свидетельство не выдается до 1 января 2021 г.
По окончанию действия приказа № 327н (после 1 января 2021 г.) лицам,
прошедшим аккредитацию специалиста, но не получившим свидетельство об
аккредитации специалиста, такие свидетельства выдаются без повторного
прохождения этапов аккредитации специалиста в порядке, предусмотренном
приказами Минздрава России от 2 июня 2021 г. № 334н « Об утверждении Положения
об аккредитации специалистов» (далее – Положение об аккредитации специалистов)
и от 6 июня 2021 г. № 352н «Об утверждении порядка выдачи свидетельства об
аккредитации специалиста, формы свидетельства об аккредитации специалиста и
технических требований к нему».
2. Пунктом 3 приказа № 327н устанавливается, что сертификаты специалиста,
срок действия которых заканчивается в период с 6 апреля 2020 г. включительно (дата
вступления в силу постановления № 440), продлеваются на 12 месяцев с даты
окончания срока их действия (т.е., например, если срок действия сертификата
заканчивается 27 апреля 2020 г., то он продлевается до 27 апреля 2021 г.
включительно). При этом получение нового сертификата специалиста или
осуществление иных действий по продлению срока его действия со стороны
медицинских и фармацевтических работников не требуется.
3. Приложением к приказу № 327н установлены случаи и условия допуска
физических лиц к осуществлению медицинской деятельности и (или)
фармацевтической деятельности без получения сертификата специалиста или
свидетельства об аккредитации специалиста, которые применяются в случае
чрезвычайной ситуации и (или) при возникновении угрозы распространения
заболевания, представляющего опасность для окружающих, до 1 января 2021 г. (далее
– приложение к приказу № 327н).
4. В соответствии с подпунктом «а» пункта 1 приложения к приказу
№ 327н допуск лиц, завершивших обучение по программам высшего медицинского и
фармацевтического образования (бакалавриат, специалитет, ординатура), среднего
профессионального образования и дополнительного профессионального образования
(профессиональная переподготовка, повышение квалификации), в период до 1 января
2021 г. осуществляется без свидетельства об аккредитации специалиста и
сертификата специалиста, а равно и без прохождения аккредитации специалиста и
сдачи сертификационного экзамена.
Допуск указанных лиц к медицинской и (или) фармацевтической деятельности
осуществляется по специальностям в соответствии с полученными документами об
образовании (т.е., например, лицо, прошедшее обучение по программе ординатуры
по специальности «Кардиология», допускается к профессиональной деятельности по
специальности «Кардиология»).
5. В соответствии с подпунктом «б» пункта 1 приложения к приказу
№ 327н лица, получающие в настоящее время высшее медицинское образование по
программам ординатуры по одной из специальностей укрупненной группы
специальностей «Клиническая медицина» (приказ Минобрнауки России от 12
сентября 2021 г. № 1061) и до завершения такого обучения (т.е. сдачи ГИА и
получения диплома) вне зависимости от объема освоенной образовательной
программы (года обучения) могут быть трудоустроены на период, указанный в
пункте 3 настоящего письма, на должность врача-стажера при условии прохождения
обучения по краткосрочным дополнительным профессиональным программам (не
менее 36 часов). Данные лица осуществляют медицинскую деятельность под
контролем врача-специалиста.
Указанное правило также применяется в отношении лиц, которые будут
приняты на обучение по программам ординатуры в 2020 году, с момента начала
обучения в 2020/2021 учебном году.
6. В соответствии с подпунктом «в» пункта 1 приложения к приказу
№ 327н лица, обучающихся на выпускных курсах по программам среднего
профессионального образования по одной из специальностей укрупненной группы
специальностей «Клиническая медицина» (приказ Минобрнауки России от 29
октября 2021 г. № 1199) могут быть трудоустроены на должность специалиста со
средним медицинским образованием и допущены к осуществлению медицинской
деятельности на период, указанный в пункте 3 настоящего письма, при условии
прохождения обучения по краткосрочным дополнительным профессиональным
программам (не менее 36 часов); трудоустройство. Данные лица осуществляют
медицинскую деятельность под контролем старшей медицинской сестры.
Указанное правило, в том числе, распространяется с начала нового учебного
года (с 1 сентября 2020 г.) на студентов, которые будут переведены на выпускные
курсы на обучение в 2020/2021 учебного году.
7. В соответствии с подпунктом «г» пункта 1 приложения к приказу
№ 327н лица, имеющие медицинское образование, полученное в Российской
Федерации (подтверждаемое соответствующим дипломом), и не работавшие по своей
специальности более пяти лет, могут быть трудоустроены на должность врачастажера (для специалистов с высшим медицинским образованием) или должность
специалиста со средним медицинским образованием (для специалистов со средним
медицинским образованием) и допущены к осуществлению медицинской
деятельности на период, указанный в пункте 3 настоящего письма, при условии
прохождения обучения по краткосрочным дополнительным профессиональным
программам (не менее 36 часов).
8. По истечению периода, указанного в пункте 3 настоящего письма,
трудоустроенные лица, допущенные к осуществлению медицинской и
фармацевтической деятельности в соответствии с подпунктами «а» – «г» пункта 1
приложения к приказу № 327н, для продолжения осуществления такой деятельности,
подлежат прохождению аккредитации специалиста по соответствующей
специальности в порядке, предусмотренном Положением об аккредитации
специалистов.

Оцените статью
Мой сертификат
Добавить комментарий