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

 

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

Цели создания политики ИБ:

• Формирование организационно распорядительной или методической базы.
• Формирование единых принципов построения системы обеспечения информационной безопасности.

 

Задачи:

• Формирование организационно-распорядительной базы для реализации системы обеспечения информационной безопасности.
• Разработка модели нарушителя информационной безопасности объекта.
• Разработка перечня и анализа информационных угроз объекта.
• Классификация информационных ресурсов объекта и их контроль.
• Разработка требований предъявленных к информационной системе в корпоративной сети.
• Формирование требований к системе обеспечения информационной безопасности.

 

Управление доступом:

• Формальные процедуры удаления учётных записей пользователей.
• Правила определения полномочий пользователей.
• Процедура управления паролями.
• Правила пересмотра правд доступа пользователей.

Этапы разработки политики безопасности.

 

1) Первоначальный аудит безопасности.

a. Проведение обследований.

b. Идентификация угроз безопасности.

c. Идентификация ресурсов.

d. Оценка рисков.

2) Разработка.

3) Внедрение.

4) Аудит и контроль.

5) Пересмотр и корректировка.

Антивирусная и парольная политика безопасности.

 

1. Сотрудники обязаны самостоятельно генерировать пароли для доступа в сеть.

2. Хранить в тайне свой личный пароль.

3. Регулярно, не реже одного раза в месяц, производить смену пароля.

4. Подвергать антивирусному контролю любую информацию передаваемую по каналам связи.

5. При обнаружении заражённых файлов сотрудники обязаны:

a. Приостановить работу.

b. Оповестить сотрудников отдела ИБ.

c. Провести анализ необходимости использования файлов.

d. Вызвать специалиста по уничтожению заражённых файлов.

6. Сотрудник должен сообщать о:

a. Обнаружении целостности пломб.

b. Несанкционированном изменении в конфигурации аппаратных и программных средств.

c. Отклонении в нормальной работе.

d. Перебоях в системе электропитания.

e. Использовании недокументированных свойств ПО.

7. Присутствовать при работе по внесению модификации рабочего места.

8. Пресекать попытки несанкционированного использования ПК другими сотрудниками.

9. Контролировать переносные устройства хранения данных.

Основные функциональные обязанности администратора безопасности.

 

• Участия в разработке основополагающих документов.
• Информирование сотрудников о политике информационной безопасности.
• Настройка аппаратных и программных средств.
• Анализ угроз информационной безопасности.
• Контроль выполнения требований по работе с информацией и ПК.

Разработка политики информационной безопасности.

 

1) Первоначальный аудит безопасности.

a. Проведение обследований.

b. Идентификация угроз безопасности.

c. Идентификация ресурсов.

d. Оценка рисков.

2) Разработка.

3) Внедрение.

4) Аудит и контроль.

5) Пересмотр и корректировка.

Сервер Kerberos.

 

Kerberos – это программный продукт, разработанный в середине 1980-х годов в Массачусетском технологическом институте и претерпевший с тех пор ряд принципиальных изменений. Клиентские компоненты Kerberos присутствуют в большинстве современных операционных систем.

Kerberos предназначен для решения следующей задачи. Имеется открытая (незащищенная) сеть, в узлах которой сосредоточены субъекты – пользователи, а также клиентские и серверные программные системы. Каждый субъект обладает секретным ключом. Чтобы субъект C мог доказать свою подлинность субъекту S (без этого S не станет обслуживать C), он должен не только назвать себя, но и продемонстрировать знание секретного ключа. C не может просто послать S свой секретный ключ, во-первых, потому, что сеть открыта (доступна для пассивного и активного прослушивания), а, во-вторых, потому, что S не знает (и не должен знать) секретный ключ C. Требуется менее прямолинейный способ демонстрации знания секретного ключа.

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

Чтобы с помощью Kerberos получить доступ к S (обычно это сервер), C (как правило – клиент) посылает Kerberos запрос, содержащий сведения о нем (клиенте) и о запрашиваемой услуге. В ответ Kerberos возвращает так называемый билет, зашифрованный секретным ключом сервера, и копию части информации из билета, зашифрованную секретным ключом клиента. Клиент должен расшифровать вторую порцию данных и переслать ее вместе с билетом серверу. Сервер, расшифровав билет, может сравнить его содержимое с дополнительной информацией, присланной клиентом. Совпадение свидетельствует о том, что клиент смог расшифровать предназначенные ему данные (ведь содержимое билета никому, кроме сервера и Kerberos, недоступно), то есть продемонстрировал знание секретного ключа. Значит, клиент – именно тот, за кого себя выдает. Подчеркнем, что секретные ключи в процессе проверки подлинности не передавались по сети (даже в зашифрованном виде) – они только использовались для шифрования. Как организован первоначальный обмен ключами между Kerberos и субъектами и как субъекты хранят свои секретные ключи – вопрос отдельный.

 

Здесь c и s – сведения (например, имя), соответственно, о клиенте и сервере, d1 и d2 – дополнительная (по отношению к билету) информация, Tc.s – билет для клиента C на обслуживание у сервера S, Kc и Ks – секретные ключи клиента и сервера, {info}K – информация info, зашифрованная ключом K.

Приведенная схема – крайне упрощенная версия реальной процедуры проверки подлинности. Более подробное рассмотрение системы Kerberos можно найти, например, в статье В. Галатенко "Сервер аутентификации Kerberos (Jet Info, 1996, 12-13). Нам же важно отметить, что Kerberos не только устойчив к сетевым угрозам, но и поддерживает концепцию единого входа в сеть.

Протокол TLS/SSL.

 

TLS (Transport Layer Security) - криптографический протокол, обеспечивающий защищённую передачу данных между узлами в сети Интернет.

TLS-протокол основан на Netscape SSL-протоколе версии 3.0 и состоит из двух частей - TLS Record Protocol и TLS Handshake Protocol. Различие между SSL 3.0 и TLS 1.0 незначительные, поэтому далее в тексте термин «SSL» будет относиться к ним обоим.

 

TLS предоставляет возможности аутентификации и безопасной передачи данных через Интернет с использованием криптографических средств. Часто происходит лишь аутентификация сервера, в то время как клиент остается неаутентифицированным. Для взаимной аутентификации каждая из сторон должна поддерживать инфраструктуру открытого ключа (PKI), которая позволяет защитить клиент-серверные приложения от перехвата сообщений, редактирования существующих сообщений и создания поддельных.

 

SSL включает в себя три основных фазы:

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

 

Клиент и сервер, работающие по TLS, устанавливают соединение, используя процедуру handshake ("рукопожатие"). В течение этого handshake, клиент и сервер принимают соглашение относительно параметров, используемых для установления защищенного соединения.

 

Последовательность действий при установлении TLS соединения:

• Клиент подключается к TLS — поддерживаемому серверу и запрашивает защищенное соединение.
• Клиент предоставляет список поддерживаемых алгоритмов шифрования и хеш-функций.
• Сервер выбирает из списка, предоставленного клиентом, наиболее устойчивые алгоритмы, которые так же поддерживаются сервером, и сообщает о своем выборе клиенту.
• Сервер отправляет клиенту цифровой сертификат для собственной идентификации. Обычно цифровой сертификат содержит имя сервера, имя доверенного центра сертификации и открытый ключ сервера.
• Клиент может связаться с сервером доверенного центра сертификации и подтвердить аутентичность переданного сертификата до начала передачи данных.
• Для того чтобы сгенерировать ключ сессии для защищенного соединения, клиент шифрует случайно сгенерированную цифровую последовательность открытым ключом сервера и посылает результат на сервер. Учитывая специфику алгоритма асимметричного шифрования, используемого для установления соединения, только сервер может расшифровать полученную последовательность, используя свой закрытый ключ.

 

В данной текущей версии протокола доступны следующие алгоритмы:

 

• Для обмена ключами и проверки их подлинности применяются комбинации алгоритмов: RSA (асимметричный шифр), Diffie-Hellman (безопасный обмен ключами), DSA (алгоритм цифровой подписи) и алгоритмы технологии Fortezza.
• Для симметричного шифрования: RC2, RC4, IDEA, DES, Triple DES или AES.
• Для хэш-функций: MD5 или SHA.

Протокол SSH.

 

SSH (Secure Shell) - сетевой протокол прикладного уровня, позволяющий производить удалённое управление операционной системой и туннелирование TCP-соединений (например, для передачи файлов). Сходен по функциональности с протоколами Telnet и rlogin, но, в отличие от них, шифрует весь трафик, включая и передаваемые пароли. SSH допускает выбор различных алгоритмов шифрования. SSH-клиенты и SSH-серверы имеются для большинства сетевых операционных систем.

SSH позволяет безопасно передавать в незащищенной среде практически любой другой сетевой протокол, таким образом, можно не только удаленно работать на компьютере через командную оболочку, но и передавать по шифрованному каналу звуковой поток или видео (например, с веб-камеры). Также SSH может использовать сжатие передаваемых данных для последующего их шифрования, что удобно, например, для удаленного запуска клиентов X Window System.

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

 

Рекомендации по безопасности использования SSH:

• Запрещение удаленного root-доступа.
• Запрещение подключения с пустым паролем или отключение входа по паролю.
• Выбор нестандартного порта для SSH-сервера.
• Использование длинных SSH2 RSA-ключей (2048 бит и более). По состоянию на 2006 год система шифрования на основе RSA считалась надёжной, если длина ключа не менее 1024 бит. *) (см. КОММЕНТАРИЙ В КОНЦЕ ТЕКСТА)
• Ограничение списка IP-адресов, с которых разрешен доступ (например, настройкой файрвола).
• Запрещение доступа с некоторых потенциально опасных адресов.
• Отказ от использования распространенных или широко известных системных логинов для доступа по SSH.
• Регулярный просмотр сообщений об ошибках аутентификации.
• Установка детекторов атак (IDS, Intrusion Detection System).
• Использование ловушек, подделывающих SSH-сервис (honeypots).

Протокол IPSec.

 

IPsec (IP Security) - набор протоколов для обеспечения защиты данных, передаваемых по межсетевому протоколу IP, позволяет осуществлять подтверждение подлинности и/или шифрование IP-пакетов. IPsec также включает в себя протоколы для защищённого обмена ключами в сети Интернет.

 

Протоколы IPsec работают на сетевом уровне (уровень 3 модели OSI). Это делает IPsec более гибким, поскольку IPsec может использоваться для защиты любых протоколов базирующихся на TCP и UDP. В то же время увеличивается его сложность из-за невозможности использовать протокол TCP (уровень OSI 4) для обеспечения надёжной передачи данных.

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

IPsec-трафик может маршрутизироваться по тем же правилам, что и остальные IP-протоколы, но, так как маршрутизатор не всегда может извлечь информацию, характерную для протоколов транспортного уровня, то прохождение IPsec через NAT-шлюзы невозможно. Для решения этой проблемы IETF определила способ инкапсуляции ESP в UDP, получивший название NAT-T (NAT traversal).

IPsec можно рассматривать как границу между внутренней (защищённой) и внешней (незащищённой) сетью. Эта граница может быть реализована как на отдельном хосте, так и на шлюзе, защищающем локальную сеть. Заголовок любого пакета, проходящего через границу, анализируется на соответствие политикам безопасности, то есть критериям, заданным администратором. Пакет может быть либо передан дальше без изменений, либо уничтожен, либо обработан с помощью протоколов защиты данных. Для защиты данных создаются так называемые SA (Security Associations) — безопасные соединения, представляющие собой виртуальные однонаправленные каналы для передачи данных. Для двунаправленной связи требуется два SA.

Параметры политик безопасности и безопасных соединений хранятся в двух таблицах: базе данных политик безопасности (SPD — Security Policy Database) и базе данных безопасных соединений (SAD — Security Association Database). Записи в SPD определяют в каких случаях нужно включать шифрование или контроль целостности, в то время как в SAD хранятся криптографические ключи, которые будут использованы для шифрования или подписи передаваемых данных. Если согласно SPD передаваемый пакет должен быть зашифрован, но в SAD нет соответствующего SA, реализация IPsec по протоколу IKE согласовывает с другой стороной создание нового SA и его параметры.

 

Протокол S-HTTP.

 

S-HTTP представляет собой безопасный протокол связи, ориентированный на сообщения и разработанный для использования в сочетании с HTTP. Он предназначен для совместной работы с моделью сообщений HTTP и легкой интеграции с приложениями HTTP. Этот протокол предоставляет клиенту и серверу одинаковые возможности (он одинаково относится к их запросам и ответам, а также к предпочтениям обеих сторон). При этом сохраняется модель транзакций и эксплуатационные характеристики HTTP.

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

Протокол S-HTTP поддерживает безопасные сквозные (end-to-end) транзакции, что выгодно отличает его от базовых механизмов идентификации HTTP, которые требуют, чтобы клиент попытался получить доступ и получил отказ и лишь затем включают механизм безопасности. Клиенты могут быть настроены таким образом, чтобы любая их транзакция автоматически защищалась (обычно с помощью специальной метки в заголовке сообщения). Такая настройка, к примеру, часто используется для передачи заполненных бланков. Если вы используете протокол S-HTTP, вам никогда не придется отправлять важные данные по сети в незащищенном виде.

S-HTTP поддерживает высокий уровень гибкости криптографических алгоритмов, режимов и параметров. Для того, чтобы клиенты и серверы смогли выбрать единый режим транзакции (Так, например, им нужно решить, будет ли запрос только шифроваться или только подписываться или и шифроваться и подписываться одновременно. Такое же решение нужно принять и для ответов.), используется механизм согласования опций, криптографических алгоритмов (RSA или Digital Signature Standard [DSA] для подписи, DES или RC2 для шифрования и т.д.), и выбора сертификатов (Например: "Подписывайтесь своим сертификатом Verisign"). S-HTTP поддерживает криптографию общих ключей и функцию цифровой подписи и обеспечивает конфиденциальность данных.

Протокол SSL.

 

SSL (Secure Sockets Layer - уровень защищённых сокетов) - криптографический протокол, обеспечивающий безопасную передачу данных по сети Интернет. При его использовании создаётся защищённое соединение между клиентом и сервером. SSL изначально разработан компанией Netscape Communications. Впоследствии на основании протокола SSL 3.0 был разработан и принят стандарт RFC, получивший имя TLS.

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

SSL состоит из двух уровней. На нижнем уровне многоуровневого транспортного протокола (например, TCP) он является протоколом записи и используется для инкапсуляции (то есть формирования пакета) различных протоколов (SSL работает совместно с таким протоколами как POP3, IMAP, XMPP, SMTP и HTTP). Для каждого инкапсулированного протокола он обеспечивает условия, при которых сервер и клиент могут подтверждать друг другу свою подлинность, выполнять алгоритмы шифрования и производить обмен криптографическими ключами, прежде чем протокол прикладной программы начнёт передавать и получать данные.

Для доступа к веб-страницам, защищённым протоколом SSL, в URL вместо обычного префикса (schema) http, как правило, применяется префикс https, указывающий на то, что будет использоваться SSL-соединение. Стандартный TCP-порт для соединения по протоколу https — 443.

Для работы SSL требуется, чтобы на сервере имелся SSL-сертификат.