По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Прямо сейчас, пока ты читаешь эту статью, в серверной комнате организации А под толстым слоем пыли, окруженная множеством переплетенных проводов мигает разноцветными лампочками офисная АТС. Но давайте будем тише - дежурный IT - специалист, скорее всего спит, поставив переадресацию на мобильный телефон - а вдруг что - то сломается?
Вообще, облака, на своем старте - наделали шума. Все начали задаваться вопросом - а зачем нам сервер в офисе, когда можно арендовать VPS/VDS/SaaS в облаке и “не париться”?
В статье мы ответим на вопрос - почему одни компании выносят свою телефонию в облако или покупают услугу виртуальной АТС, тем самым создавая возможность поставить вендинговую машину или настольный теннис в серверной комнате, а другие, продолжают перебирать провода, протирать пыль с серверов и наслаждаться мерцанием цветовых серверных индикаторов от офисной АТС.
Бюджет: сравниваем облако и размещение в офисе
Первое, что стоит спросить себя - а как мы будем платить за АТС? Что для нас важно, а что нет? Мы, как интегратор, все чаще сталкиваемся с тем, что в компаниях (SMB) идет сокращение бюджета на IT и соответствующие отделы находят выходы из этой ситуации.
С точки зрения локальной (офисной) АТС - далее мы будем называть ее порой “on-premise” решение (говоря так, мы чувствуем себя немного круче), IT - отдел экономит деньги ежемесячной оплате хосту (SaaS платформе, которая дает вам услугу виртуальной АТС). Но эта экономия реальна только в том случае, если вы не меняете аппаратные компоненты сервера с АТС. В таком случае модель вы платите только за услуги провайдера, электричество и заработную плату IT’шнику. Модель “купил - запитал - работает, не трожь” работает, более чем.
Однако, в случае выхода из строя того или иного компонента, компания несет определенного рода дополнительные расходы. Отметим, опять же, на нашем опыте - случается это редко. Современные сервера имеют высокое качество комплектующих, и если вы не планируете поливать сервера водой, обдавать из огнемета или выставлять на улице - скорее всего, данная неприятность вам не грозит.
Не менее важный фактор - обновление ПО. Проблема в том, что если вы обновляете программное обеспечение офисной “on-premise” (да - да, мы же предупреждали) АТС, есть риск выхода из строя. Опять же, данная проблема решается простым резервированием, так называемой отказоустойчивостью, по принципу Active - Standby (один сервер активен, а второй в резерве и всегда готов выйти в активную роль). Этот нюанс требует дополнительной проработки, а следовательно, дополнительных денежных затрат.
Теперь про масштабируемость. В случае, если проснувшись в один прекрасный день вы осознаете, что ваш бизнес вырос в разы (вы сходили на бизнес - тренинг, к шаману или проделали магический обряд), то офисные локально размещенные станции масштабируются несколько сложнее и затратнее, чем виртуальные. Это отражается на деньгах и стоимости масштабирования.
Тут есть важный пункт - офисная АТС гораздо более гибка, чем виртуальная. Дело в том, что виртуальная АТС дается вам в неком готовом контейнере предустановок, где SaaS платформа редко дает возможность доработки станции. Да, признаем, некоторые облачные АТС имеют API, но когда вопрос заходит о масштабном изменении логики работы АТС (кастомизация скриптами, например) - тут происходит коллапс. В этом плане офисные АТС явно выигрывают перед облачными, несмотря на стоимость затрат на эту самую кастомизацию. Просто сам факт ее возможность при быстром росте бизнеса - это преимущество (поверьте, знаем о чем говорим на опыте разных проектов).
Редкие, но некоторые IT - отделы предпочитают облачную телефонию. Это более предсказуемо и снимает с них часть ответственности. Например, когда директор компании задает вопрос ITшнику почему не работает телефония, тот может смело спихнуть ответственность на виртуального хостера.
Модернизация и апгрейд: витаем в облаках или в офисе?
Тут пальму первенства заслуженно забирают облака. Дело в том, что если у вас в офисе живет on-premise АТС, так или иначе, рано или поздно вам придётся обновлять аппаратные компоненты сервера (процессор, оперативная память, наращивать мощность RAID массивов, тем самым увеличивая пространство для хранения данных). Это происходит по двум причинам: растёт нагрузка на сервер и текущие мощности уже не справляются, или обновление программного обеспечения требует более производительных комплектующих. При облачном размещении таких проблем нет - ваш хост автоматически наращивает мощности виртуальной машины, внутри которой живет ваша АТС. Это, безусловно, сказывается на мощности, но выходит дешевле покупки комплектующих под локальных сервак.
Кстати про обновление - в случае решения, размещённого в вашем офисе, обновление ПО производят ваши ITшники, тогда как при размещении в облаке, хост сам обновляет ПО и раскатывает их на боевую среду.
Интеграция телефонии с внешними системами
Любителям on-premise решений посвящается. Откиньтесь на диване поудобнее - в этой главе уже есть победитель. И это не облако.
Дело в том, что с ростом компании, уровень технологичности неизбежно повышается. Новые направления деятельности и увеличение потока клиентов обязывают связать ИТ - узлы в единую экосистему: интеграция телефонии и CRM, справочниками, базами данных, звонки по нажатию, триггерный автоматический обзвон, предиктивный дайлер и прочие. Все эти “хотелки” так или иначе требуют доработки вашей станции, так как интеграцию со всем на свете разработчики облачный виртуальных АТС предусмотреть не могут, а открыть исходный код и раздвинув горизонт кастомизации до бесконечности, рискуют получить уязвимости в безопасности.
Именно по этой причине, офисная коробка дает больше. Например: вы хотите сделать маршрутизацию на базе гороскопа клиента. В вашей CRM есть номер телефона клиента, имя и его дата рождения. При входящем звонке, телефония “смотрит” в вашу CRM и видит месяц рождения клиента (по номеру, с которого он звонит). Кастомная прослойка понимает - он рыба, а рыбам, сегодня не рекомендуется иметь деловых отношений. И на базе этого решения офисная телефонная станция терминирует вызов. Как вам?
Пожалуй, надо признать, пример весьма спорный. Но посыл понятен - коробка в офисе даст больший пул возможностей, а облако, максимум, обрезанный API.
Катастрофы: коробки или облако?
В офисе над вами прорвало трубу и залило серверную (мы реально встречали такие кейсы). Сервера вышли из строя, не работает ничего. Есть две новости, начнем с хорошей:
Сервер был на гарантии и имеется контракт на горячую замену от интегратора;
Сервера больше нет.
Несмотря на контракт горячей замены, просто в минимум 24 часа вам гарантирован (если не реализована схема отказоустойчивости с географически распределенными серверами по ЦОДам).
В облаке, как правило, SaaS дает вам гарантию работоспособности от 90%. Облачная вычислительная мощность живет в разных ЦОДах, при отказе аппаратного сервера, виртуальная машина с вашей ВАТС переедет на другой аппаратный сервер за сотые доли секунды. Что неплохо.
Тут, пожалуй, для SMB компании первенство мы отдадим облаку.
Итоги
Как облака, так и размещенные в офисе решения имеют свои преимущества. Если курс вашей компании на безграничную кастомизацию, интеграцию всех ИТ - систем между собой для создания экосистемы и амбициозные бизнес - процессы, у вас есть грамотный IT - специалист, то выбирайте коробку, которую вы разместите в офисе.
Если вы не хотите проблем с сервером, обслуживанием, вы малый бизнес, у вас нет своего IT’шника в штате и хотите рабочую телефонию с минимумом головной боли - облако подойдет под ваши требования.
Введение
Однажды в организации, где я работаю, случился Asterisk
Случился не без моего участия, а если быть точным, то я и был главным виновником, и как следствие - главным исполнителем. Напасть была локальной, но достаточно быстро получила широкое распространение, хотя, в отдельных уголках приходилось нести прогресс в массы с применением тяжелой артиллерии и напалма. В итоге Asterisk`ом было охвачено порядка полутора тысяч абонентов.
Процесс настройки абонента изначально выглядел следующим образом:
Включил телефон, обновил прошивку. Пока он перезагружается, завел абонента на Asterisk (создал запись для регистрации SIP-клиента). Далее, самый очевидный способ настройки телефона - web-интерфейс; набрал в адресной строке браузера IP-адрес телефона, авторизовался, настроил два десятка параметров и готово. На всё ушло 2-3 минуты.
Следующий абонент - повторяем.
На втором десятке абонентов начало надоедать, появилось желание как-нибудь упростить процесс.
Заглянул в настройки: экспорт и импорт конфигурации присутствует; сохранил конфигурацию телефона в файл, заглянул в него - обычный текстовый файл, в котором перечислены параметры с их значениями.
Нашел параметры, значения которых менял в web-интерфейсе, причем большинство из этих параметров, хоть и отличается от дефолтных, но одинаково для всех настраиваемых в рамках данной организации телефонов. Таким образом, имея эталонный файл конфигурации и редактируя в нем всего 5-6 строк, я получал конфигурации для остальных телефонов, которые "заливал" в аппараты всё через тот же web-интерфейс.
Спустя какое-то время количество абонентов заметно выросло, компания продолжала развиваться, сотрудники мигрировали между подразделениями, увольнялись, появлялись новые, некоторые телефоны выходили из строя, и возня с файлами стала постепенно отнимать много времени и раздражала с каждым днем всё больше. Тут я вспомнил про пункт меню из web-интерфейса, в котором были написаны многообещающие слова "Auto Provision".
Обратимся за определением к производителям телефонов. У Dlink или Fanvil мы получим следующее:
Auto Provisioning используется для реализации удаленной/автоматической инсталляции, развертывания конфигурационных и некоторых других связанных файлов.
Snom дает нам практически такое же:
Auto Provisioning может использоваться для предоставления общих и специфических параметров конфигурации на телефоны и для актуализации прошивки.
Вроде бы всё устраивает, значит, будем для наших целей отталкиваться от этих определений.
Вариантов автоматической настройки предусмотрено несколько, и без долгих терзаний, как наиболее понятный и доступный был выбран следующий:
Развертывание конфигурации с tftp сервера, адрес которого телефон будет получать по DHCP в Option 66.
Разберемся вкратце, что есть что.
TFTP - простой протокол передачи файлов (Trivial File Transfer Protocol). В отличие от FTP основан на транспортном протоколе UDP и в нем отсутствует возможность аутентификации (однако, возможна фильтрация по IP-адресу). Одно из основных преимуществ TFTP - простота реализации клиента, поэтому он достаточно широко используется в частности для загрузки обновлений и конфигураций сетевых устройств.
DHCP - протокол динамической настройки узла (Dynamic Host Configuration Protocol); сетевой протокол, позволяющий сетевым устройствам автоматически получать IP-адрес и другие параметры, необходимые для работы в сети TCP/IP.
Не вдаваясь глубоко в подробности, схема обмена сообщениями DHCP при получении параметров выглядит следующим образом:
DHCPDISCOVER: клиент (в нашем случае, телефон) передает это сообщение broadcast, и использует его для поиска DHCP-серверов в своей канальной среде.
В одном из полей этого пакета, в поле options, клиент передает список необходимых ему опций, наиболее распространенными из которых являются:
(1) - Subnet Mask
(3) - Router
(6) - Domain Name Server
(15) - Domain Name
именно в этом поле клиент сообщает о том, что ему нужен адрес tftp сервера для загрузки конфигурационного и/или других связанных файлов. Номер опции, которая его содержит - 66 (у cisco есть аналогичная опция 150, основное отличие которой в том, что она может содержать адреса нескольких tftp серверов).
DHCPOFFER: cервер отвечает на запрос клиента. Сервер может передать это сообщение как broadcast так и unicast (зависит от значений полей полученных от клиента). В этом сообщении сервер предлагает клиенту параметры, которые он может отдать в текущей конфигурации. Если в сегменте сети клиента несколько DHCP серверов, то получив запрос, они все отправляют OFFER-ы.
После того, как клиент выбрал, OFFER какого из DHCP серверов принять, он отправляет следующий пакет:
DHCPREQUEST: казалось бы, если клиент определился, какой DHCP сервер "пришелся ему по душе", можно передать unicast-запрос этому серверу; однако предается broadcast, чтобы уведомить остальные DHCP серверы о своём выборе (добавляется опция 54, указывающая адрес выбранного DHCP-сервера), и они могли освободить зарезервированные OFFER-ы.
DHCPACK: cервер отправляет подтверждение клиенту. После этого клиент настраивает свой сетевой интерфейс, используя предоставленные параметры и опции.
В различных ситуациях могут еще возникать DHCPDECLINE, DHCPNAK, DHCPRELEASE, DHCPINFORM, но их рассмотрение в рамки данной статьи не входит.
Для получения исчерпывающей информации о работе DHCP можно обратиться к RFC 2131:
https://tools.ietf.org/html/rfc2131
Про опции 66 и 150 можно почитать здесь:
https://wiki.merionet.ru/ip-telephoniya/67/dhcp-opciya-150-i-66/
https://blog.router-switch.com/2013/03/dhcp-option-150-dhcp-option-66/
Про настройку DHCP сервера и Option 66 на Mikrotik можно почитать здесь:
https://wiki.merionet.ru/seti/5/nastrojka-dhcp-servera-na-mikrotik/
Чтобы передать телефону адрес tftp сервера, с которого он может получить конфигурационный файл, на DHCP сервере в параметрах области задаем Option 66, в которой указываем hostname либо IP адрес нашего tftp сервера.
Настройки по-умолчанию в большинстве телефонов подразумевают получение IP-адреса по DHCP и запрос Option 66.
В итоге, телефон получает IP, получает адрес tftp сервера и пытается "стянуть" оттуда файл своей конфигурации.
Согласно документации Dlink, загрузка файла конфигурации происходит следующим образом:
Устанавливается соединение с сервером.
Проверяется наличие файла с соответствующим именем:
- в первую очередь проверяется файл с именем соответствующим аппаратной платформе;
- во вторую - соответствующий MAC адресу устройства;
- в третью - соответствующий ID устройства;
- файл с произвольным именем проверяется либо в последнюю очередь (DHCP option, UpnP) либо в первую, если он явно указан в конфигурации телефона.
Проверяется версия конфигурационного файла.
Если версия выше, чем текущая на телефоне, файл конфигурации применяется.
Как уже говорилось ранее, файл конфигурации представляет собой текстовый документ определенного вида:
Первая строка: <<VOIP CONFIG FILE>>Version:2.0002
Для того, чтобы конфигурация была применена, версия файла должна быть выше, нежели текущая на телефоне, инкрементировать требуется последний разряд версии. По-умолчанию версия конфигурации 2.0002
Пример:
Текущая версия конфигурации 2.0002 на одном телефоне и 2.0004 на еще двух. Для того чтобы конфигурация применилась только на один телефон в первой строке файла конфигурации ставим <<VOIP CONFIG FILE>>Version:2.0004
для того чтобы обновить конфигурацию на всех телефонах ставим в первой строке
<<VOIP CONFIG FILE>>Version:2.0005
Разделы:
<GLOBAL CONFIG MODULE - содержит данные о сетевых настройках, серверах DNS, SNTP...
<LAN CONFIG MODULE> - содержит данные о настройках LAN, режимах работы LAN
<TELE CONFIG MODULE> - настройки расширенных функций телефонной части (Call Feature)
<DSP CONFIG MODULE> - настройка кодеков
<SIP CONFIG MODULE> - настройки SIP, серверы, регистрация etc...
<PPPoE CONFIG MODULE> - настройки PPPoE
<MMI CONFIG MODUL>E - настройки доступа и WEB интерфейса
<QOS CONFIG MODULE> - qos и vlan
<DHCP CONFIG MODULE> - настройки внутреннего DHCP
<NAT CONFIG MODULE> - настройки NAT и ALG
<PHONE CONFIG MODULE> - настройки телефонной части, в этом же разделе настраивается remote phonebook и extension key.
<SCREEN KEY CONFIG MODULE> - настройка программных клавиш (для версии F3)
<AUTOUPDATE CONFIG MODULE> - настройки Autoprovision
<VPN CONFIG MODULE> - настройки VPN
<TR069 CONFIG MODULE> - настройки TR069
Заканчивается файл строкой <<END OF FILE>>
Для обновления какой-либо опции конфигурации телефона, чтобы файл конфигурации был принят телефоном достаточно наличие следующих полей:
<<VOIP CONFIG FILE>> Version:2.0002
<Название необходимого раздела>
Название опции: значение
<<END OF FILE>>
Например, для обновления имени хоста телефона необходимо создать следующий файл конфигурации:
<<VOIP CONFIG FILE>>Version:2.0003
<GLOBAL CONFIG MODULE>
Host Name :ReceptionPhone
<<END OF FILE>>
Все остальные элементы являются необязательными.
Итак, овал нарисован.
Остались сущие мелочи - реализовать инструмент для создания конфигураций и дальнейшего управления ими. Займемся этим в следующей публикации.
В этой статье расскажем о различных концепциях и стратегиях, которые реализуют многие организации для защиты своих активов как от внутренних, так и от внешних киберугроз.
Вы узнаете об этих трех основных принципах, и о том, как они используются в различных организациях. Кроме того, вы узнаете о ключевых терминах безопасности и моделях контроля доступа.
При подключении устройства к сети и Интернету, организации открывают двери для хакеров, которые могут проникнуть в их сеть и нанести ущерб. Есть много организаций, которые используют только брандмауэр в своей сети и поэтому думают, что и их внутренняя сеть, и пользователи защищены от угроз в Интернете. Брандмауэр, как единственное сетевое устройство, развернутое между внутренней сетью и Интернетом, — это просто первый уровень безопасности для всей организации. Многие люди задаются вопросом: а не достаточно ли брандмауэра для фильтрации вредоносного входящего и исходящего трафика?
Много лет назад ответ был бы однозначно «да». Однако, поскольку хакеры всегда ищут новые стратегии для проникновения в сеть, мы не можем полагаться только на один уровень безопасности для защиты наших активов. Ответ на этот вопрос уже не является однозначным «да» просто потому, что существует много типов трафика, которые используют небезопасные сетевые протоколы для обмена сообщениями между источником и получателем.
Ниже приведены лишь некоторые из многих вопросов, которые должен задать специалист по кибербезопасности:
Осуществляет ли организация активный мониторинг сообщений Domain Name System (DNS) на предмет угроз?
Есть ли в организации какие-либо решения для обеспечения безопасности, защищающие входящие и исходящие сообщения электронной почты компании?
Если в сети происходит кибератака, существуют ли системы для упреждающего блокирования и оповещения отдела информационных технологий?
Есть ли в организации специальная группа или человек по безопасности для управления общей безопасностью всего предприятия?
Существуют ли какие-либо политики безопасности и технические средства контроля для защиты внутренней сети?
Многие поставщики систем безопасности используют маркетинговые стратегии и используют модные слова (buzzwords), чтобы повлиять на потенциальных клиентов для приобретения их устройств безопасности «все в одном». Ключевой момент, который упускают многие не осведомленные клиенты, — это то, как решение или продукт безопасности будет защищать всех пользователей и все типы трафика, защищать их при использовании небезопасных протоколов и так далее. Примером может служить использование endpoint protection (защиты конечных точек). Вы можете рассматривать это решение как антивирусное программное обеспечение с централизованным управлением для администратора. Хотя многие решения для защиты от вредоносных программ конечных точек предлагают расширенные функции. Это все еще первый уровень безопасности, который просто защищает хост.
Не все решения для защиты конечных точек или антивирусы, защищают от угроз, связанных, например с электронной почтой. Проще говоря, организация не может полагаться только на один подход для защиты своих активов, ей нужен многоуровневый подход, известный как Глубокая защита (Defense in Depth - DiD).
Стратегия DiD подразумевает, что один уровень безопасности не должен использоваться в качестве единственной меры противодействия кибератакам. Если этот единственный уровень не сможет защитить сеть, тогда все (активы) будут открыты для взлома хакерами. В DiD реализован многоуровневый подход для защиты всех активов от различных типов кибератак, где, если один уровень не может защитить актив, то есть другой уровень для обеспечения безопасности.
Эту тактику наслаивания придумали в Агентстве национальной безопасности (NSA) как комплексный подход к информационной и электронной безопасности. А изначально - это военная стратегия, которая направлена на то, чтобы заставить атакующего тратить как можно больше времени на преодоление каждого уровня защиты, нежели предотвратить наступление противника.
Концепция Defense in Depth делит организацию защиты инфраструктуры на три контролируемые части:
Физическая: сюда относятся все меры по ограничению физического доступа к ИТ-инфраструктуре неавторизованных лиц. Например, охранник офиса, системы СКУД, камеры видеонаблюдения, сигнализация, телекоммуникационные шкафы с замками и так далее.
Техническая: сюда относятся все хардварные и софтовые средства защиты информации, призванные контролировать сетевой доступ к объектам информационной системы, межсетевой экран, средства антивирусной защиты рабочих станций, прокси-серверы, системы аутентификации и авторизации.
Административная: сюда относятся все политики и процедуры информационной безопасности, принятые в организации. Данные документы призваны регулировать управление защитой, распределение и обработку критичной информации, использование программных и технических средств в компании, а также взаимодействие сотрудников с информационной системой, сторонними организациями и другими внешними субъектами.
Многоуровневый подход -это как защита короля в его замке. Если произойдет нападение, захватчикам потребуется пройти несколько уровней обороны, включая стражей на входе и другие препятствия, прежде чем они смогут добраться до короля (актива).
Чтобы лучше понять важность DiD, давайте углубимся в изучение трех основных принципов информационной безопасности, так называемой триады CIA:
Конфиденциальность (Confidentiality)
Целостность (Integrity)
Доступность (Availability)
Каждый принцип играет жизненно важную роль в обеспечении информационной безопасности любой организации. В следующем подразделе вы узнаете о характеристиках конфиденциальности, целостности и доступности, а также о том, как они используются в отрасли для обеспечения безопасности наших сетей.
Конфиденциальность
Поскольку все больше людей подключаются к сетям и обмениваются информацией, будь то их частная сеть дома, корпоративная сеть в офисе или даже Интернет, конфиденциальность является серьезной проблемой.
Каждый день организации генерируют новые данные, отправляя и получая сообщения между устройствами. Представьте себе организацию, которая использует электронную почту в качестве единственной платформы обмена сообщениями. Каждый человек создает сообщение электронной почты, которое является данными, и эти данные используют некоторое пространство для хранения в локальной системе. Когда адресат получает электронное письмо, оно сохраняется на компьютере получателя. Важно, чтобы сообщение получили только те, кому оно адресовано, посторонние лица его увидеть не должны.
Когда эти данные передаются по сети, их также можно перехватить. Поэтому специалист по безопасности также должен принимать во внимание следующие вопросы: является ли соединение безопасным? Является ли протокол связи безопасным? Является ли сеть безопасной?
Конфиденциальность (Confidentiality) гарантирует, что сообщения и другие данные будут храниться в тайне от посторонних лиц или устройств. В области информационных технологий конфиденциальность реализуется в виде шифрования данных. Люди используют устройства для выполнения задач, будь то отправка электронной почты, загрузка файла или даже отправка сообщения в мессенджере со смартфона. Важно всегда защищать эти сообщения.
Данные обычно существуют в следующих состояниях:
Данные в состоянии покоя
Данные в движении (транзит)
Используемые данные
Данные в состоянии покоя — это данные, которые не используются ни приложением, ни системой. В данный момент они хранятся на носителях, таких как жесткий диск (HDD) в локальной или удаленной системе. Когда данные находятся в состоянии покоя, они уязвимы для злоумышленников, пытающихся либо украсть, либо изменить их. Специалисты по безопасности реализуют как методы аутентификации, так и алгоритмы шифрования для защиты любых данных в состоянии покоя. Примером может служить использование BitLocker в операционной системе Microsoft Windows 10, которая позволяет администратору создавать зашифрованный контейнер, а затем пользователь может поместить файлы в эту специальную область памяти и заблокировать ее.
После того, как содержимое BitLocker заблокировано (закрыто) пользователем, и контейнер, и его содержимое шифруются. Следовательно, доступ предоставляется только в том случае, если пользователь предоставляет правильные учетные данные для открытия и расшифровки содержимого. Если злоумышленник украдет зашифрованный контейнер, он не сможет просмотреть содержимое из-за шифрования данных.
Данные в движении определяются как данные, которые передаются между источником и пунктом назначения. Представьте, что есть сотрудники, которые работают дистанционно или работают в удаленном месте вдали от офиса. Этим людям может потребоваться часто подключаться к корпоративной сети для доступа к сетевым ресурсам, например, при доступе или работе с документами, находящимися на файловом сервере. Как специалисты в области кибербезопасности, мы должны быть осведомлены о том, какие типы защиты или механизмы безопасности существуют для защиты данных, передаваемых между устройством пользователя и файловым сервером. Кроме того, устройства отправляют и получают сообщения почти каждую секунду, и некоторые из этих сообщений обмениваются с использованием небезопасных протоколов, что позволяет злоумышленнику перехватывать сообщения (данные) по мере их передачи по сети. Если данные передаются по сети в незашифрованном формате, злоумышленник может увидеть все содержимое в виде открытого текста и собрать конфиденциальную информацию, такую как логины и пароли.
Это всего лишь несколько возможных ситуаций, которые могут возникнуть, когда данные находятся в движении. Некоторые рекомендуемые действия заключаются в том, чтобы всегда, когда это возможно, использовать защищенные сетевые протоколы и гарантировать, что удаленные сотрудники, используют виртуальную частную сеть (VPN) для шифрования трафика между устройством пользователя и корпоративной сетью.
Чтобы лучше понять необходимость VPN, представьте, что организация имеет несколько филиалов и хочет «расшарить» ресурсы из головного офиса в удаленный филиал. Использование Интернета небезопасно, особенно для передачи корпоративных данных между филиалами. Одним из решений может быть использование Wide Area Network (WAN), предоставляемой интернет-провайдером (ISP). Если организация решает использовать WAN, это означает, что за эту услугу придется платить, а для некоторых компаний это решение может оказаться не по карману. В качестве альтернативы, если организация имеет подключение к Интернету и брандмауэры находятся в каждом офисе, специалист по безопасности может настроить VPN между двумя устройствами брандмауэра. Этот тип VPN известен как site-to-site VPN.
На следующем рисунке показано представление site-to-site VPN:
Как показано на рисунке, site-to-site VPN устанавливает безопасное зашифрованное соединение между головным офисом и удаленными филиалами через Интернет. Следовательно, любые сообщения, которые перемещаются между офисами, шифруются и отправляются через туннель VPN, защищая сообщения от неавторизованных пользователей.
Существует также другой тип VPN - с удаленным доступом (remote access VPN). Этот тип позволяет пользователю установить VPN-туннель между конечным устройством, таким как ноутбук, и брандмауэром организации. Этот тип VPN позволяет сотрудникам, работающим дома или на ходу, безопасно подключаться к сети организации и получать доступ к сетевым ресурсам. Имейте в виду, что на устройстве сотрудника должен быть установлен VPN-клиент, который используется для установления безопасного соединения между компьютером и корпоративным брандмауэром.
На следующем рисунке приведен пример VPN с удаленным доступом:
Используемые данные — это данные, к которым в данный момент обращается или использует приложение. В этом состоянии данные наиболее уязвимы. В качестве примера используемых данных представьте, что вы открываете PDF-документ с помощью приложения для чтения PDF-файлов. Прежде чем приложение сможет успешно открыть файл PDF, документ необходимо расшифровать, если файл защищен паролем. После ввода правильного пароля документ будет представлен пользователю в незашифрованном виде. Важно обеспечить постоянную безопасность системы и приложений, которые обращаются к данным и/или используют их.
Таким образом, конфиденциальность — это защита ваших активов от посторонних лиц или устройств.
Целостность
Целостность (Integrity) играет важную роль в нашей повседневной жизни, это степень сформированности, собранности, проявление гармонии соотношения и взаимодействия частей. Вышло немного по-философски, но тот же принцип необходим и в сети. Представьте, что вы получили письмо от друга через местное отделение почты и открыв его, кажется, что с его содержимым все в порядке. Как получатель, вы могли бы предположить, что содержимое письма осталось неизменным в процессе доставки, но как вы можете проверить, было ли содержимое изменено человеком или устройством по пути? В сети очень важно обеспечить, чтобы данные или сообщения не изменялись в процессе передачи между источником и получателем.
В кибербезопасности используются специальные алгоритмы хеширования, чтобы помочь пользователям и устройствам проверить, было ли сообщение изменено или нет при его передаче. Алгоритмы хеширования создают односторонний криптографический хэш (дайджест, он же контрольная сумма), который является математическим представлением сообщения. Это означает, что только это сообщение может выдавать одно и то же хэш-значение. Алгоритмы хеширования создают одностороннюю функцию, которая делает практически невозможным изменение и определение содержимого самого сообщения.
На следующем рисунке показан процесс хеширования сообщения:
Как показано на рисунке, сообщение проходит через криптографический алгоритм, который создаёт одностороннюю хэш-функцию сообщения. Когда пользователь или устройство хочет отправить сообщение адресату, и сообщение, и его хеш-значение упаковываются вместе и отправляются по сети. Когда получатель получает входящее сообщение, он выполняет свою собственную функцию хеширования сообщения и вычисляет его хеш-значение.
Затем получатель сравнивает хеш-значение, полученное от отправителя, с хеш-значением, которое он высчитал. Если оба значения хеш-функций совпадают, это означает, что сообщение не было изменено во время передачи и целостность сохранена. Однако, если хэши не совпадают, это указывает на то, что сообщение было подвергнуто изменению, и получатель просто удалит его.
Помимо этого, хэширование также помогает убедиться в том, что сообщение не было искажено в результате каких-либо сбоев или неполадок в сети.
Доступность
Существуют типы кибератак, которые блокируют или затрудняют доступ законных пользователей к ресурсу. Другими словами, злоумышленники пытаются нарушить доступность (availability) данных и ресурсов. В области кибербезопасности доступность гарантирует, что данные и ресурсы всегда доступны для пользователей и систем, которым разрешен доступ к этим ресурсам.
Простым примером кибератаки, которая может быть использована для нарушения доступности сети, является атака «распределенный отказ в обслуживании» Distributed Denial of Service (DDoS). Этот тип атаки запускается из нескольких географических точек и нацелен на одну систему или сеть. Злоумышленник направляет к объекту атаки огромное количество легитимных запросов или другого типа трафика, в результате чего, система перегружается и становится неспособной обработать запросы от других пользователей. Цель состоит в том, чтобы сделать целевую систему или сеть непригодными для использования или недоступными для других пользователей.
Cloudflare (www.cloudflare.com) обеспечивает неограниченную защиту от DDoS-атак для пользователей. Администратор может перенести свои записи DNS в Cloudflare для управления службами DNS. Таким образом, Cloudflare находится между общедоступным сервером и остальной частью Интернета. Если на ресурс будет направлен DDoS-трафик из любой точки мира, он должна будет проходить через сеть Cloudflare, что смягчит атаку.
Возможно вы считаете, что для злоумышленников важно, чтобы сетевые ресурсы и данные были всегда доступны, чтобы их можно было взломать или украсть. Но на самом деле существуют злоумышленники, цель которых - сделать так, чтобы эти ресурсы не были больше доступны для пользователей.
Просто представьте что злоумышленник взломает систему управления энергосистемой вашего города или района. Если хакеру удастся отключить эту систему, то не будет электричества, и это затронет большинство потребителей и организаций. В таких ситуациях важно, чтобы специалисты внедрили меры безопасности, которые смогут защитить критически важные процессы, системы и сети от взлома.
Объединение трех принципов
Некоторые организации ставят одни принципы выше других. Например, компания может больше внимание уделять на защите своих данных с помощью различных систем аутентификации и шифрования. Этот принцип фокусируется на конфиденциальности. Сосредоточение внимания на одном компоненте, таком как конфиденциальность, в большей степени, чем на других, повлечет меньшее внимание к другим - целостности и/или доступности.
Вы можете задаться вопросом: и в чём здесь проблема? Представьте себе, что организация применяет самые строгие меры безопасности для предотвращения любого несанкционированного доступа к своим системам и сети. Чтобы авторизованный пользователь мог получить доступ к этим ресурсам, ему необходимо будет предоставить, возможно, несколько проверок своей личности, например, при многофакторной аутентификации (MFA), и даже пароли для открытия файлов. В результате доступ к ресурсам будет усложнен для всех, включая авторизованных пользователей, поэтому доступность немного пострадает.
На следующем рисунке показана триада принципов и точка фокусировки в центре:
Ключевой момент заключается в том, чтобы всегда обеспечивать баланс при реализации конфиденциальности, целостности и доступности в любой системе и сети. Важно уделять одинаковое внимание всем основным направлениям просто для того, чтобы не было недостатка ни в одном аспекте информационной безопасности.