1с-битрикс – ssl-сертификаты: что это такое и как правильно выбрать
Коллеги! С вами , руководитель интернет-агентства .
Последнее время SSL-технологии вызывают большой интерес, их доля в доменных зонах растет. Несмотря на популярность, многие не понимают, что это такое. Мы расскажем, что называют SSL-сертификатами, зачем они нужны и как их выбирать.
Для чего нужен SSL-сертификат
SSL-сертификат — это своеобразное «удостоверение» сайта, подтверждающее его безопасность для пользователей. На сайте с SSL-сертификатом пользователи могут совершать покупки и вводить пароли, не опасаясь, что их данные перехватят злоумышленники. Сам сертификат представляет собой набор файлов, установленных на сервер.
Сударь, защищайте свой сайт!
Как узнать, установлен ли на сайте SSL-сертификат
Замок или зеленая строка рядом с доменным именем в браузерной строке означают, что на сайте установлен SSL-сертификат и вся информация передается по защищенному протоколу, значит, никто не украдет ваши пароли и другую конфиденциальную информацию.
Как работает технология SSL
Для безопасной передачи данных между пользовательским браузером и сервером используется инфраструктура ключей. Она позволяет зашифровать передаваемую информацию (необходим открытый ключ) и расшифровать ее (известный только владельцу закрытый ключ). Инфраструктура ключей подчиняется стандарту x.509, определяющему состав электронного сертификата:
- номер версии (1-3);
- порядковый номер;
- название выдавшей сертификат компании;
- идентификатор алгоритма подписи;
- период действия;
- имя владельца сертификата;
- открытый ключ владельца;
- цифровая подпись.
Нужно отметить, что стандарт x.509 не устанавливает определенного алгоритма шифрования; при этом наиболее часто используется RSA.
Подробнее остановимся на том, зачем используют сертификаты, и какие задачи они выполняют.
Каждый SSL-сертификат должен выполнять три функции, а именно:
- шифровать передаваемую информацию;
- проводить аутентификацию, т.е. проверять веб-ресурс на подлинность;
- сохранять целостность передаваемых данных.
Все это помогает пользователю убедиться в том, что ресурс, к которому подключен сертификат, безопасен и ему можно доверять.
Не очень-то внушает доверие, да?
Рассмотрим на примере функции SSL-сертификатов
Представьте ситуацию: девушка Мария собирается купить авиабилет на сайте компании-перевозчика. Для этого ей нужно отправить данные своей банковской карты, защитив их от перехвата сторонними лицами. Чтобы не сомневаться в безопасности покупки, Мария проверяет, есть ли на сайте SSL-сертификат. Сделать это просто: надо убедиться, что в начале адресной строки обозначено https-соединение (его обычно выделяют зеленым цветом). Такое обозначение подтверждает, что данные между браузером пользователя и сервером авиакомпании зашифрованы. В этом случае у компании-перевозчика есть два ключа – общедоступный открытый и закрытый ключ, который известен только сотрудникам организации. Зашифрованную открытым ключом информацию может расшифровать только закрытый ключ и наоборот. Если выбранная Марией компания пользуется сертификатом, выданным действующим центром сертификации, то браузер покупательницы определит его как доверенный, т.е. произойдет аутентификация. После этого браузер при помощи открытого ключа зашифрует данные. Опасаться утечки информации не стоит, даже если мошенникам удастся перехватить данные: они не смогут их прочитать, поскольку у них нет доступа к закрытому ключу.
Самоподписанные сертификаты
SSL-сертификат действует в течение ограниченного времени, кроме того, чтобы его получить, нужно заплатить определенную сумму. Поэтому многие выбирают самоподписанные сертификаты, которые можно бесплатно сгенерировать на веб-сервере, воспользовавшись панелью управления. Однако такая экономия не всегда целесообразна.
Все браузеры проверяют, был ли сертификат выдан специальным центром. Если нет (как в случае с самоподписанным сертификатом), на экране появится надпись: «Сертификат безопасности сайта не является доверенным!».
Ваш сертификат подозрителен
Такое предупреждение с высокой вероятностью насторожит потенциальных клиентов, и они покинут ресурс. Вывод: самоподписанные сертификаты – плохой выбор для интернет-магазинов или сайтов с высоким трафиком. Однако они подходят для внутреннего использования, например, в небольшой компании, сотрудникам которой известно о происхождении сертификата, добавленного в доверенные. Помимо этого, самозаверенные сертификаты пригодны для разработки и тестирования приложений, если используется сервер Apache.
Виды SSL-сертификатов
Если вы хотите купить SSL-сертификат в центре сертификации, вам нужно знать об их разновидностях. При выборе необходимо учитывать несколько критериев:
- желаемая степень доверия к сайту;
- количество доменов и поддоменов, для которых нужен сертификат;
- статус покупателя: физическое или юридическое лицо;
- бюджет на приобретение сертификата.
Остановимся на каждом из перечисленных пунктов более подробно.
Валидность ресурсов подтверждается одной из трех степеней проверки, поэтому SSL-сертификаты по типу валидации делятся на 3 разновидности:
- Domain Validation. Сертификаты подтверждают право владения доменом.
- Organization Validation. Сертификаты подтверждают не только домен, но и факт юридического существования компании.
- Extended Validation. Сертификаты с расширенной проверкой компании.
Domain Validation
У доступных DV-сертификатов скромные возможности: они просто проверяют принадлежность домена владельцу сертификата. Domain Validation подходит для небольших сайтов, блогов со средним количеством посетителей и форумов.
DV-сертификат можно получить без предоставления дополнительных документов. Их выпускают в течение 5-10 минут, а стоимость сертификата колеблется от 1000 до 4000 рублей. Domain Validation доступен и физическим, и юридическим лицам и обеспечивает начальный уровень защиты.
Organization Validation
Солидные OV-сертификаты – это не только подтверждение бизнес-статуса компании, но и способ обеспечить доверие пользователей. Владельцам интернет-магазинов или другого онлайн-бизнеса рекомендуется выбирать именно этот вид сертификатов.
OV-сертификат – это обеспечение среднего уровня защиты. Сертификат доступен только для юрлиц, его выпускают в срок до 5 дней. Годовая стоимость сертификата — 4000-50000 рублей. Для получения OV-сертификата потребуются копии документов и номер телефона собственника организации и телефонной компании, где указано название фирмы.
Extended Validation
Высокая стоимость EV-сертификатов компенсируется их надежностью. Такие сертификаты – выбор крупных компаний, которые заботятся о безопасности и своем имидже. EV-сертификат обеспечивает более высокий уровень защиты в сравнении с другими сертификатами. Он доступен только юридическим лицам, поддерживает кириллические домены. Extended Validation выпускается в срок от 3 до 10 дней, а его годовая стоимость колеблется от 10 до 100 тысяч рублей.
Получить такой сертификат можно только при предъявлении ряда документов: уведомления о регистрации юрлица, извещения о регистрации в качестве страхователя и т.д.
Проверив документацию, провайдер может позвонить по указанному компанией номеру, и этот звонок станет дополнительным этапом проверки. Хотя получение EV-сертификата требует немало времени и усилий, это оправдано: сайт будет иметь высокий уровень доверия. У сайтов с EV-сертификатом в адресной строке есть панель зеленого цвета – свидетельство высокого статуса организации. Нажав на панель, пользователи могут также получить полные сведения о компании. Такие сертификаты надежно защищают от фишинга, поскольку мошенники не могут пройти все уровни проверки. Благодаря строгим правилам верификации, поддельные EV-сертификаты встречаются крайне редко.
Выбирая SSL-сертификат, учитывайте возможности своего бюджета и специфику вашего бизнеса. Используйте опыт своих партнеров и конкурентов, изучите крупные известные сайты. Например, WildBerries.ru пользуется SGC OV SSL Wildcard с максимальным уровнем защиты, а Tinkoff.ru — EV SSL от Thawte.
Тщательно проверяйте название организации: киберпреступники могут создать «липовую» фирму со схожим названием, привязав к ней сертификат.
При выборе сертификата часто возникает вопрос об одновременной защите нескольких поддоменов или разных доменов, расположенных на одном сервере. В таком случае лучше купить SAN (UCC) сертификат для мультидоменных проектов. Чтобы защитить только несколько поддоменов, подойдут Wildcard-сертификаты. С их помощью вы обеспечите шифрование как основного домена, так и поддоменов типа subdomain1.domain.com и т.д. Защита основного домена предусмотрена не для каждого Wildcard-сертификата – обратите на это внимание перед покупкой. Хотя такие сертификаты удобны и экономичны, иногда дешевле купить отдельные сертификаты для каждого поддомена.
Крупные поставщики SSL-услуг — Symantec, Thawte и Comodo. По сути, они продают практически идентичные продукты. Отличие заключается в сервисе. Symantec обладает большой пролонгированной гарантией — до 1,75 млн. долларов. Эта сумма полагается покупателю, если компания понесла убытки из-за нарушения обязательств со стороны Symantec. Кроме того, компания предлагает антивирусную защиту, которая ежедневно сканирует страницы на хосте покупателя и выявляет вредоносные программы. Такой привлекательный функционал стоит дорого – цена сертификатов от Symantec превышает стоимость продуктов от Thawte и Comodo. Thawte предлагает продукцию средней стоимости (без дополнительных функций), а Comodo является поставщиком с более демократичными ценами (плюс антивирусная защита и сервис PCI-анализа).
Отметим, что сегодня владельцы сайтов часто покупают SSL-сертификаты у хостинг-провайдеров.. Благодаря большим объемам продаж, стоимость сертификатов часто оказывается ниже стоимости продукта от прямого поставщика.
Важно: поддержка IDN предусмотрена не во всех сертификатах. Может случиться так, что сертификат с безупречным сочетанием цены, качества и функционала не подойдет для кириллического домена. Чтобы не ошибиться с выбором, приобретайте сертификаты с поддержкой IDN у GlobalSign, Thawte, Comodo или Symantec.
Уязвимость SSL-сертификатов
SSL-сертификат – это не волшебная палочка, способная решить все вопросы безопасности. Несмотря на всю сложность механизмов криптографического шифрования, человеческий фактор все равно доминирует. Простой пример: в сентябре 2021 года Symantec выпустила целых 164 нелегитимных сертификата для 76 доменных имен. Это произошло из-за ошибки сотрудников компании.
Слежу за легитимностью твоего SSl
Хранение закрытого ключа тоже связано с некоторыми трудностями. Его не получится изолировать от всего мира: секретный ключ часто используется при https-соединении. Из-за этого есть риск взлома сервера с целью получения закрытого ключа. Здесь опять доминирует человеческий фактор: если происходит взлом, то в этом, вероятнее всего, виноват администратор, который не защитил сервер. Чтобы обезопасить закрытые ключи, их владельцы устанавливают пароли.
Поведем итоги
Несколько рекомендаций о том, как выбрать SSL-сертификат. Учитывайте опыт конкурентов. Обратите внимание, какими сертификатами пользуются компании с аналогичной продукцией, охватом аудитории и способом обмена данными с пользователями.
Не забывайте, что сайты с https ранжируются Google выше, чем другие. Сайты без сертификатов, которые принимают номера и пароли банковских карт, определяются Google Chrome как небезопасные. Это еще один веский довод в пользу приобретения SSL-сертификата. Сегодня https-соединение доступнее для пользователей, чем еще несколько лет назад. Некоторые компании проводят выгодные акции и иногда дарят сертификаты в качестве бонуса.
Напоминаем, что на линейку готовых решений INTEC: Universe действуют скидки:
Читайте другие наши статьи:
Авторизация с помощью сертификата ssl на nginx let’s encrypt
Добрый день, вечер или ночь, все зависит от времени суток в который вам довелось прочитать мою статью.
В связи с ростом количества корпоративных клиентов, было принято решение дать доступ к учетной системе внешним пользователям. Для самостоятельного оформления заказов и отслеживания их состояний. Реализация была создан web интерфейс с необходимым функционалом и доступом. Тут же стал вопрос безопасности, кроме стандартных пользователь-пароль было решено еще усилить безопасность, для этого применили OpenVPN, но появились клиенты, для которых нельзя применять OpenVPN (политики безопасности, нежелания и.д.), тут на глаза попались статьи про доступ по ssl сертификату.
Исходные данные:
Сервер с учетной программой web интерфейс находятся в DMZ;
WEB-server на nginx, на него проброшены порты http(80) и https(443);
На web-server настроен proxy_pass на сервер с учетной программой, доступ только по порту 8080 и только с IP web-server, большего доступа с серверу нет(обычная безопасность);
На сайт для доступа установлен сертификат от Let’s Encrypt.
Переходим к самому процессу создания сертификата пользователя:
Для сертификатов будем использовать каталог “/etc/ssl/crm.example.ru”
Создаём структуру каталогов:
# mkdir /etc/ssl/crm.example.ru
# cd /etc/ssl/crm.example.ru
# mkdir db
# mkdir db/certs
# mkdir db/newcerts
# touch db/index.txt
# echo "01" > db/serial
# chmod 700 ./
Создаем конфигурационный файл для подписи сертификатов.
/etc/ssl/crm.example.ru/ca.conf”
[ ca ]
default_ca = CA_CITENAME # Секция по умолчанию для подписи сертификатов
[ CA_CITENAME ]
droot = /etc/ssl/crm.example.ru # Корневой каталог хранилища
dir = $droot/db # Каталог базы хранилища
certs = $dir/certs # Каталог сертификатов
new_certs_dir = $dir/newcerts # Каталог для новых сертификатов (pem)
database = $dir/index.txt # Файл базы сертификатов
serial = $dir/serial # Файл серийного номера
# Файл доверенного сертификата
certificate = $droot/ca.crt
# Закрытый ключ доверенного сертификата
private_key = $droot/ca.key
default_days = 365 # Срок действия нового сертификата (дни)
default_crl_days = 7 # Срок действия списка отозванных сертификатов
default_md = md5 # Использовать алгоритм MD5
policy = policy_citename # Политика секции
[ policy_citename ]
countryName = optional # Необязательный параметр
stateOrProvinceName = optional # .......................
localityName = optional # .......................
organizationName = optional # .......................
organizationalUnitName = optional # .......................
commonName = supplied # обязательный параметр
emailAddress = supplied # .....................
[ req_distinguished_name ]
countryName = Название страны (2-буквенный код)
countryName_default = RU
countryName_min = 2
countryName_max = 2
stateOrProvinceName = Название области (полное название)
stateOrProvinceName_default = Tyumen region
localityName = Название местности (например, город)
localityName_default = Tyumen
0.organizationName = Название организации
0.organizationName_default = EXAMPLE
organizationalUnitName = Название организационной единицы (например, отдел)
commonName = Ваше имя
commonName_max = 64
emailAddress = Email адрес
emailAddress_max = 64
Создаем самоподписанный сертификат и новый ключ сервера без пароля:
# openssl req -new -newkey rsa:2048 -nodes -keyout ca.key -x509 -days 365
-subj "/C=RU/ST=Tyumen region/L=Tyumen/O=EXAMPLE/OU=CRM/CN=crm.example.ru/emailAddress=crm@example.ru"
-out ca.crtЛибо, если хотите всё вводить вручную.
# openssl req -new -newkey rsa:2048 -nodes -keyout ca.key -x509 -days 365 -out ca.crtПросмотреть данные закрытого ключа и сертификата вы можете с помощью команд:
# openssl rsa -noout -text -in ca.key (для ключа)
# openssl x509 -noout -text -in ca.crt (для сертификата)
Создание клиентского закрытого ключа и запроса на сертификат (CSR):
# openssl req -new -newkey rsa:2048 -nodes -keyout client01.key
-subj "/C=RU/ST=Tyumen region/L=Tyumen/O=EXAMPLE/OU=CRM/CN=User example1/emailAddress=user@example1.ru"
-out client01.csr
Либо, если хотите всё вводить вручную.
#openssl req -new -newkey rsa:2048 -nodes -keyout client01.key -out client01.csr
Заместо User example1 можно указать почту клиента, а за место EXAMPLE компанию клиента, это поможет отслеживать сертификаты.
В результате выполнения команды появятся два файла 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
Подготовка данных для передачи клиенту. Для передачи полученных в результате предыдущих операций файлов клиенту, обычно используется файл в формате PKCS#12. В этот файл упаковывается и защищается паролем вся информация необходимая клиенту для инсталляции сертификата в броузер.
# openssl pkcs12 -export -in client01.crt -inkey client01.key
-certfile ca.crt -out client01.p12 -passout pass:123ewqasdcxz
Выставляем права доступа на ключи.
# chmod 600 /etc/ssl/crm.example.ru/client*.crt
# chmod 600 /etc/ssl/crm.example.ru/client*.key
Переместим все созданные файлы в каталог db/certs на хранение.
# mv ./client01.* db/certs/
В nginx надо установить:
ssl_client_certificate /etc/ssl/crm.example.ru/ca.crt;
ssl_verify_client on;
ssl_verify_depth 1;
Для того чтобы клиент смог подключиться по сертификату ему необходимо отправить файл client01.p12 и ca.crt, а так же сообщить пароль для установки сертификата. ca.crt необходим, так как мы не используем его для сертификации сервера, для этомо используеться Let’s Encrypt.
Процесс выдачи сертификатов можно автоматизировать, написать просто скрипт не составит труда. У нас таких клиентов не много, около 15, так что вбить всё руками не составило проблем.
Мой рабочий пример:
Окно выбора сертификата:
Сам сертификат:
Работоспособность Let’s Encrypt:
В подготовке материала помогли статьи:
→ «Авторизация клиентов в nginx посредством SSL сертификатов»
→ «Авторизация по SSL сертификатам»
→ «Авторизация с помощью клиентских SSL сертификатов. (ssl crypt mod_ssl apache)»
→ «Великий и могучий Google»
P.S. Проверка проводилась на Google Chrome.
Технологии и инструменты обеспечения безопасности информации в системах и сетях
Основной особенностью любой сетевой структуры (системы) является то, что её компоненты распределены в пространстве и связь между ними осуществляется физически при помощи сетевых соединений (коаксиальный кабель, витая пара, оптоволокно, радиосвязь и т. п.) и программно — при помощи механизма сообщений.
Сетевые системы характерны тем, что, наряду с обычными (локальными) непреднамеренными действиями и атаками, осуществляемыми в пределах одной компьютерной системы, к ним применим специфический вид атак, обусловленный распределенностью ресурсов и информации в пространстве.
Это так называемые сетевые (или удалённые) атаки (RemoteNetwork Attacks). Они характеризуются, во-первых, тем, что злоумышленник может находиться за тысячи километров от атакуемого объекта, и, во-вторых, тем, что нападению может подвергаться не конкретный компьютер, а информация, передающаяся по сетевым соединениям.
С развитием локальных и глобальных сетей именно удалённые атаки становятся лидирующими как по количеству попыток, так и по успешности их применения и, соответственно, обеспечение безопасности вычислительных и информационных систем и сетей с точки зрения противостояния удалённым атакам приобретает первостепенное значение.
Современные сервисы безопасности функционируют в распределенной среде, поэтому необходимо учитывать наличие как локальных, так и сетевых угроз. В качестве общих можно выделить следующие угрозы:
- обход злоумышленником защитных средств;
- осуществление злоумышленником физического доступа к вычислительной установке, на которой функционирует сервис безопасности;
- ошибки администрирования, в частности, неправильная установка, ошибки при конфигурировании и т.п.;
- переход сервиса в небезопасное состояние в результате сбоя или отказа, при начальной загрузке, в процессе или после перезагрузки;
- маскарад пользователя (попытка злоумышленника выдать себя за уполномоченного пользователя, в частности, за администратора). В распределенной среде маскарад может реализовываться путем подмены исходного адреса или воспроизведения ранее перехваченных данных идентификации/аутентификации;
- маскарад сервера (попытка злоумышленника выдать свою систему за легальный сервер), следствием маскарада сервера может стать навязывание пользователю ложной информации или получение от пользователя конфиденциальной информации;
- использование злоумышленником чужого сетевого соединения или интерактивного сеанса (например, путем доступа к оставленному без присмотра терминалу);
- несанкционированное изменение злоумышленником конфигурации сервиса и/или конфигурационных данных;
- нарушение целостности программной конфигурации сервиса, в частности, внедрение троянских компонентов или получение контроля над сервисом;
- несанкционированный доступ к конфиденциальной (например, регистрационной) информации, в том числе несанкционированное расшифрование зашифрованных данных;
- несанкционированное изменение данных (например, регистрационной информации), в том числе таких, целостность которых защищена криптографическими методами;
- несанкционированный доступ к данным (на чтение и/или изменение) в процессе их передачи по сети;
- анализ потоков данных с целью получения конфиденциальной информации.
- перенаправление потоков данных (в частности, на системы, контролируемые злоумышленником);
- блокирование потоков данных;
- повреждение или утрата регистрационной, конфигурационной или иной информации, влияющей на безопасность функционирования сервиса (например, из-за повреждения носителей или переполнения регистрационного журнала);
- агрессивное потребление злоумышленником ресурсов, в частности, ресурсов протоколирования и аудита, а также полосы пропускания;
- сохранение остаточной информации в многократно используемых объектах.
Ввиду особой опасности таких атак — особенно для государственных предприятий и органов власти — к системам защиты информации предъявляются повышенные требования. Например, для защиты конфиденциальной информации в органах исполнительной власти следует удовлетворить следующие требования [Петренко С., Курбатов В., 2005].
- Выбор конкретного способа подключения к сети Internet, в совокупности обеспечивающего межсетевое экранирование с целью управления доступом, фильтрации сетевых пакетов и трансляции сетевых адресов для скрытия структуры внутренней сети, проведение анализа защищенности узла Интернет, а также использование средств антивирусной защиты и централизованное управление средствами защиты должны производиться на основании рекомендаций документа Гостехкомиссии РФ СТР-К.
- Автоматизированные системы защиты (АСЗ) организации должны обеспечивать защиту информации от несанкционированного доступа (НСД) по классу “1Г” в соответствии с “Руководящим документом” Гостехкомиссии РФ “РД. Автоматизированные системы. Защита от НСД к информации. Классификация АСЗ и требования по защите информации”.
- Средства вычислительной техники и программные средства АСЗ должны удовлетворять требованиям четвертого класса РД Гостехкомиссии России “РД. Средства вычислительной техники. Защита от НСД к информации. Показатели защищенности от НСД к информации”.
- Программно-аппаратные средства межсетевого экранирования, применяемые для изоляции корпоративной сети от сетей общего пользования, должны удовлетворять требованиям “РД. Средства вычислительной техники. Межсетевые экраны. Защита от НСД к информации. Показатели защищенности от НСД к информации” по третьему классу защиты.
- Информационные системы должны удовлетворять требованиям ГОСТ ИСО/ МЭК 15408 по защищенности информационных систем в рамках заданных профилей защиты.
- Во исполнение приказа Госкомсвязи России от 25 декабря 1997 года №103 “Об организации работ по защите информации в отрасли связи и информатизации при использовании сети Internet” прямое подключение АРМ по управлению оборудованием сетей связи, мониторингу, обработки данных к сети Internet должно быть запрещено.
- Программно-аппаратные средства криптографической защиты конфиденциальной информации, в том числе используемые для создания виртуальных защищенных сетей (VPN), должны иметь сертификаты ФАПСИ РФ.
- Обязательным является использование средств ЭЦП для подтверждения подлинности документов.
- Для введения использования персональных цифровых сертификатов и поддержки инфраструктуры открытых ключей для использования средств ЭЦП и шифрования необходимо создать легитимный удостоверяющий центр (систему удостоверяющих центров).
- Политика информационной безопасности должна предусматривать обязательное включение в технические задания на создание коммуникационных и информационных систем требований информационной безопасности.
- Должен быть регламентирован порядок ввода в эксплуатацию новых информационных систем, их аттестации по требованиям информационной безопасности.
Для выполнения перечисленных требований и надлежащей защиты конфиденциальной информации в государственных структурах принято использовать сертифицированные средства. Например, средства защиты от несанкционированного доступа (НСД), межсетевые экраны и средства построения VPN, средства защиты информации от утечки и прочие.
В частности, для защиты информации от НСД рекомендуется использовать программно- аппаратные средства семейств SecretNet (“Информзащита”), Dallas Lock (“Конфидент”)
, “Аккорд” (ОКБ САПР), электронные замки “Соболь” (“Информзащита”), USB-токены (“Аладдин”) и прочие. Для защиты информации, передаваемой по открытым каналам связи рекомендованы программно-аппаратные межсетевые экраны с функциями организации VPN, например, Firewall-1/VPN-1 (CheckPoint), “Застава” (“Элвис “), VipNet (“Инфотекс”), “Континент” (“Информзащита”), ФПСН-IP (“АМИКОН”) и другие.
Средства защиты информации для коммерческих структур более многообразны, среди них можно выделить следующие средства:
На основании политики информационной безопасности и указанных средств защиты информации (СЗИ) разрабатываются конкретные процедуры защиты, включающие распределение ответственности за их выполнение. Процедуры безопасности также важны, как и политики безопасности.
Если политики безопасности определяют ЧТО должно быть защищено, то процедуры определяют КАК защитить информационные ресурсы компании и КТО конкретно должен разрабатывать, внедрять данные процедуры и контролировать их исполнение.