По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Во многих наших статьях проскакивают различные команды, связанные с файловыми манипуляциями – создание директорий, файлов, установка пакетов и т.д. В данной статье мы решили начать повествование последовательно.
Основы
Итак, в Linux в отличие от Windows существует понятие полного и относительного пути. Разница между ними в том, что полный путь всегда начинается с корневого каталога (корневой каталог обозначается как /), и далее также через слеш происходит перечисление всех названий каталогов на пути к искомому файлу или директории, а в случае относительного пути – в начале слеш не указывается. То есть без слеша путь указывается относительно нынешнего местоположения, а со слешем – относительно корневого каталога. Примеры:
/home/user1/tmp/test.sh - полный путь;
~/tmp/file1 - относительный путь;
Ниже вы встретите часто используемые команды для работы с файлами, архивами и установкой программ.
Команды для работы с файлами и директориями
Команд довольно много, я перечислю самые, на мой взгляд, часто используемые:
cd - смена директории на домашнюю, можно добавлять аргументы – к примеру, cd /root;
pwd - команда покажет текущий путь к директории, в которой вы находитесь в данный момент;
ls - вывод списка файлов и каталогов по порядку (наверное, самая известная команда) если добавить модификаторы lax, то команда выведет форматированный список всех файлов и директорий (в том числе скрытые);
cat - показывает содержимое файла, к примеру – cat /root/file.txt;
tail - например, tail /root/file.txt, выводит только конец файла, удобно при работе с логами;
cp - копирование директории или файла, то есть cp /root/file.txt /etc/folder1/file.txt – из /root файл будет скопирован в указанную директорию
mkdir - создание директории, например, mkdir /root/1;
rmdir - удаление директории, синтаксис такой же, как и у команды выше;
rm -rf - очень опасная команда (и довольно популярная в интернет фольклоре), но иногда и она может пригодиться – она удаляет директорию со вложенными файлами;
mv - переименование файла или директории, сначала указывается целевая директория и затем её новое название;
locate - поиск файла с заданным названием;
Для наглядности, посмотрите на вывод команды tail
# tail install.log
Installing dosfstools-3.0.9-4.el6.i686
Installing rfkill-0.3-4.el6.i686
Installing rdate-1.4-16.el6.i686
Installing bridge-utils-1.2-10.el6.i686
Installing eject-2.1.5-17.el6.i686
Installing b43-fwcutter-012-2.2.el6.i686
Installing latrace-0.5.9-2.el6.i686
Installing trace-cmd-2.2.4-3.el6.i686
Installing crash-trace-command-1.0-5.el6.i686
*** FINISHED INSTALLING PACKAGES ***
В примере выше, команда tail вывела только последние 11 строк.
Работа с архивами
Работа с .tar архивами – очень часто встречающаяся задача, поэтому хотим привести несколько полезных команд, чтобы не пришлось лишний раз пользоваться поисковиком :)
tar cf example.tar /home/example.txt - создание .tar архива, который будет содержать в себе текстовый файл example.txt;
tar cjf example1.tar.codez2 /home/example1.txt - команда с тем же функционалом, только будет использоваться сжатие Bzip2;
tar czf example2.tar.gz /home/example2.txt - опять архивация, только на этот раз со сжатием Gzip;
tar xf example.tar - распаковка архива в текущую директорию, если тип сжатия нестандартный, то после расширения нужно добавить тип сжатия (.codez2 или .gz соответственно);
Работа с .rpm пакетами
Так как мы больше всего рассказываем и пишем про FreePBX, который по умолчанию скачивается с официального сайта вместе c СentOS, здесь место для пары команд по работе c RPM пакетами. Почему? Потому что CentOS – RPM-based Linux Distribution :) Команды требуют наличие прав супер - пользователя.
rpm -qa - вывод списка всех установленных RPM пакетов в системе;
rpm –i rpmpackage.rpm - установка пакета с именем rpmpackage;
rpm –e rpmpackage - удаление пакета с таким именем;
dpkg -i *.rpm - установка всех пакетов в директории;
Про жёсткие диски
Команда fdisk –l выводит информацию о всех подключенных жёстких и сменных дисках в системе, бывает очень полезной. Ниже пример вывод этой команды (в качестве пример рассматривается OTRS - сервер)
umask 0077
В этой серии лекций продолжается рассмотрение распределенных плоскостей управления, добавляя к изучению еще три протокола маршрутизации. Два из них являются протоколами состояния канала, а третий – единственный, широко распространенный протокол вектора пути, Border Gateway Protocol (BGP) v4.
В этих лекция мы уделим внимание тому, почему каждый из этих протоколов реализован именно так. Очень легко увлечься и запутаться в изучении мельчайших деталей работы протоколов, но нам гораздо важнее помнить о проблемах, для решения которых эти протоколы были разработаны, и о диапазоне возможных решений. Каждый изучаемый вами протокол будет представлять собой комбинацию умеренно ограниченного набора доступных решений: существует очень мало доступных новых решений. Существуют различные комбинации решений, реализованных иногда уникальными способами для решения конкретных наборов проблем.
Изучая эти принципы работы протокола, вы должны попытаться выбрать общие решения, которые они реализуют. Затем отразить эти решения обратно в набор проблем, которые должна решить любая распределенная плоскость управления, чтобы устранить проблемы в реальных сетях.
Краткая история OSPF и IS-IS
Протокол Intermediate System to Intermediate System (IS-IS или IS to IS) был разработан в 1978 году.
Open Shortest Path First (OSPF) изначально задумывался как альтернатива IS-IS, предназначенная специально для взаимодействия с сетями IPv4. В 1989 году первая спецификация OSPF была опубликована Internet Engineering Task Force, а OSPFv2, значительно улучшенная спецификация, была опубликована в 1998 году как RFC2328. OSPF, безусловно, был более широко используемым протоколом, причем ранние реализации IS-IS практически не применялись в реальном мире. Были некоторые аргументы за и против, и многие функции были «позаимствованы» из одного протокола в другой (в обоих направлениях).
В 1993 году компания Novell, в то время крупный игрок в мире сетевых технологий, использовала протокол IS-IS как основу для замены собственного протокола маршрутизации Netware. Протокол транспортного уровеня Novell, Internet Packet Exchange (IPX), в то время работал на большом количестве устройств, и возможность использования одного протокола для маршрутизации нескольких транспортных протоколов была решающим преимуществом на сетевом рынке (EIGRP, также может маршрутизировать IPX). Этот протокол замены был основан на IS-IS. Чтобы реализовать новый протокол Novell, многие производители просто переписали свои реализации IS-IS, значительно улучшив их в процессе. Это переписывание сделало IS-IS привлекательным для крупных провайдеров Интернет-услуг, поэтому, когда они отказались от протокола RIP, они часто переходили на IS-IS вместо OSPF.
Intermediate System to Intermediate System Protocol
В протоколе Intermediate System to Intermediate System (IS-IS) маршрутизатор называется Intermediate System (Промежуточной системой (IS), а хост- End System (Конечной системой (ES). Оригинальный дизайн набора состоял в том, чтобы каждое устройство, а не интерфейс, имело один адрес. Службы и интерфейсы на устройстве будут иметь точку доступа к сетевым службам (Network Service Access Point - NSAP), используемую для направления трафика к определенной службе или интерфейсу. Таким образом, с точки зрения IP, IS-IS изначально был разработан в рамках парадигмы маршрутизации хоста. Промежуточные и конечные системы связываются непосредственно с помощью протокола End System to Intermediate System (ES-IS), позволяющего IS-IS обнаруживать службы, доступные в любой подключенной конечной системе, а также сопоставлять адреса нижних интерфейсов с адресами устройств более высокого уровня.
Еще один интересный аспект дизайна IS-IS - он работает на канальном уровне. Разработчикам протокола не имело большого смысла запускать плоскость управления для обеспечения доступности транспортной системы через саму транспортную систему. Маршрутизаторы не будут пересылать пакеты IS-IS, поскольку они параллельны IP в стеке протоколов и передаются по локальным адресам связи. Когда была разработана IS-IS, скорость большинства каналов была очень низкой, поэтому дополнительная инкапсуляция также считалась расточительной. Каналы связи также довольно часто выходили из строя, теряя и искажая пакеты. Следовательно, протокол был разработан, чтобы противостоять ошибкам при передаче и потере пакетов.
Адресация OSI
Поскольку IS-IS был разработан для другого набора транспортных протоколов, он не использует адреса Internet Protocol (IP) для идентификации устройств. Вместо этого он использует адрес взаимодействия открытых систем (Open Systems Interconnect - OSI) для идентификации как промежуточных, так и конечных систем. Схема адресации OSI несколько сложна, включая идентификаторы для органа, распределяющего адресное пространство, идентификатор домена, состоящий из двух частей, идентификатор области, системный идентификатор и селектор услуг (N-селектор). Многие из этих частей адреса OSI имеют переменную длину, что еще больше затрудняет понимание системы. Однако в мире IP используются только три части этого адресного пространства.
Authority Format Identifier (AFI), Initial Domain Identifier (IDI), High-Order Domain Specific Part (HO-DSP) и область, где все обрабатывается как одно поле.
Системный идентификатор по-прежнему рассматривается как системный идентификатор.
N Selector, или NSAP, обычно игнорируется (хотя есть идентификатор интерфейса, который похож на NSAP, используемый в некоторых конкретных ситуациях).
Таким образом, промежуточные системные адреса обычно принимают форму, показанную на рисунке 1.
На рисунке 1:
Точка разделения между системным идентификатором и остальной частью адреса находится в шестом октете или если отсчитать двенадцать шестнадцатеричных цифр с правой стороны. Все, что находится слева от шестого октета, считается частью адреса области.
Если N-селектор включен, это один октет или две шестнадцатеричные цифры справа от идентификатора системы. Например, если для адреса A был включен N-селектор, это могло бы быть 49.0011.2222.0000.0000.000A.00.
Если в адрес включен N-селектор, вам нужно пропустить N-селектор при подсчете более шести октетов, чтобы найти начало адреса области.
A и B находятся в одном домене flooding рассылки, потому что у них одни и те же цифры от седьмого октета до крайнего левого октета в адресе.
C и D находятся в одном flooding domain.
A и D представляют разные системы, хотя их системный идентификатор одинаков. Однако такая адресация может сбивать с толку и поэтому не используется в реальных развертываниях IS-IS (по крайней мере, вдумчивыми системными администраторами).
Вы посчитать эту схему адресации более сложной, чем IP, даже если вы регулярно работаете с IS-IS в качестве протокола маршрутизации. Однако есть большое преимущество в использовании схемы адресации, отличной от той, которая используется на транспортном уровне в сети. Гораздо проще различать типы устройств в сети и гораздо проще отделить узлы от адресатов, если продумать алгоритм Дейкстры по кратчайшему пути (SPF).
Маршаллинг данных в IS-IS
IS-IS использует довольно интересный механизм для маршалинга данных для передачи между промежуточными системами. Каждая IS генерирует три вида пакетов:
Hello-пакеты
Пакеты с порядковыми номерами (PSNP и CSNP)
Одиночный пакет состояния канала (Link State Packet - LSP)
Единый LSP содержит всю информацию о самой IS, любых доступных промежуточных системах и любых доступных адресатах, подключенных к IS. Этот единственный LSP форматируется в Type Length Vectors (TLV), которые содержат различные биты информации. Некоторые из наиболее распространенных TLV включают следующее:
Типы 2 и 22: достижимость к другой промежуточной системе
Типы 128, 135 и 235: достижимость до пункта назначения IPv4
Типы 236 и 237: достижимость к адресату IPv6
Существует несколько типов, потому что, IS-IS изначально поддерживал 6-битные метрики (большинство процессоров на момент появления протокола могли хранить только 8 бит за раз, и два бита были «украдены» из размера поля, чтобы нести информацию о том, был ли маршрут внутренним или внешним, а также другую информацию). Со временем, по мере увеличения скорости связи, были введены различные другие метрические длины, включая 24 - и 32-битные метрики, для поддержки широких метрик.
Одиночный LSP, несущий всю информацию о доступности IS, IPv4 и IPv6, а также, возможно, теги MPLS и другую информацию, не поместится в один пакет MTU. Для фактической отправки информации по сети IS-IS разбивает LSP на фрагменты. Каждый фрагмент рассматривается как отдельный объект в процессе лавинной рассылки. Если изменяется один фрагмент, лавинной рассылкой по сети распространяется только измененный фрагмент, а не весь LSP. Благодаря этой схеме IS-IS очень эффективен при лавинной рассылке информации о новой топологии и достижимости без использования полосы пропускания, превышающей минимальную требуемую.
Обнаружение соседей и топологии
Хотя IS-IS изначально был разработан, чтобы узнать о доступности сети через протокол ES-IS, когда IS-IS используется для маршрутизации IP, он «действует так же, как протоколы IP», и узнает о достижимых местах назначения через локальную конфигурацию каждого из них. устройства и путем перераспределения из других протоколов маршрутизации. Следовательно, IS-IS - это проактивный протокол, который изучает и объявляет достижимость без ожидания пакетов, которые будут переданы и переадресованы через сеть.
Формирование соседей в IS-IS довольно просто. Рисунок 2 иллюстрирует этот процесс.
На рисунке 2:
IS A передает приветствие в сторону B. Это приветствие содержит список соседей, от которых получен сигнал, который будет пустым. Настройку времени удержания (hold time) B следует использовать для A, и добавляется к максимальному блоку передачи (MTU) локального интерфейса для канала связи. Пакеты приветствия дополняются только до завершения процесса формирования смежности. Не каждый пакет приветствия дополняется MTU канала.
IS B передает приветствие к A. Это приветствие содержит список соседей, от которых получен ответ, который будет включать A. Настройку времени удержания A следует использовать для B. Добавляется к MTU локального интерфейса.
Поскольку A находится в списке «слышимых соседей» B, A рассмотрит B и перейдет к следующему этапу формирования соседей.
Как только A включил B в список «услышанных соседей» хотя бы в одно приветствие, B рассмотрит A и перейдет к следующему этапу формирования соседа.
B отправит полный список всех записей, которые он имеет в своей таблице локальной топологии (B описывает LSP, которые он имеет в своей локальной базе данных). Этот список отправляется в Complete Sequence Number Packet (CSNP).
A проверит свою локальную таблицу топологии, сравнив ее с полным списком, отправленным B. Любые записи в таблице топологии (LSP), которых он не имеет, он будет запрашивать у B с использованием Partial Sequence Number Packet (PSNP).
Когда B получает PSNP, он устанавливает флаг Send Route Message (SRM) для любой записи в его локальной таблице топологии (LSP), запрошенной A.
Позже процесс лавинной рассылки будет проходить по таблице локальной топологии в поисках записей с установленным флагом SRM. Он заполнит эти записи, синхронизируя базы данных в A и B.
Примечание. Описанный здесь процесс включает изменения, внесенные в RFC5303, который определяет трехстороннее рукопожатие, и дополнение приветствия, которое было добавлено в большинство реализаций примерно в 2005 году.
Установка флага SRM отмечает информацию для лавинной рассылки, но как на самом деле происходит лавинная рассылка?
Надежная лавинная рассылка.
Для правильной работы алгоритма SPF Дейкстры (или любого другого алгоритма SPF) каждая IS в flooding domain должна совместно использовать синхронизированную базу данных. Любая несогласованность в базе данных между двумя промежуточными системами открывает возможность зацикливания маршрутизации. Как IS-IS гарантирует, что подключенные промежуточные системы имеют синхронизированные базы данных? В этой лекции описывается процесс создания point-to-point каналов. Далее будут описаны модификации, внесенные в процесс flooding domain по каналам с множественным доступом (например, Ethernet).
IS-IS полагается на ряд полей в заголовке LSP, чтобы гарантировать, что две промежуточные системы имеют синхронизированные базы данных. Рисунок 3 иллюстрирует эти поля.
На рисунке 3:
Длина пакета (packet length) содержит общую длину пакета в октетах. Например, если это поле содержит значение 15 , длина пакета составляет 15 октетов. Поле длины пакета составляет 2 октета, поэтому оно может описывать пакет длиной до 65 536 октетов - больше, чем даже самые большие MTU канала.
Поле оставшегося времени жизни (remaining lifetime) также составляет два октета и содержит количество секунд, в течение которых этот LSP действителен. Это вынуждает периодически обновлять информацию, передаваемую в LSP, что является важным соображением для старых технологий передачи, где биты могут быть инвертированы, пакеты могут быть усечены или информация, передаваемая по каналу связи, может быть повреждена. Преимущество таймера, который ведет обратный отсчет, а не на увеличение, состоит в том, что каждая IS в сети может определять, как долго ее информация должна оставаться действительной независимо от каждой другой IS. Недостаток в том, что нет четкого способа отключить описанный функционал. Однако 65 536 секунд - это большое время - 1092 минуты, или около 18 часов. Повторная загрузка каждого фрагмента LSP в сети примерно каждые 18 часов создает очень небольшую нагрузку на работу сети.
LSP ID описывает сам LSP. Фактически, это поле описывает фрагмент, поскольку оно содержит идентификатор исходной системы, идентификатор псевдоузла (функцию этого идентификатора рассмотрим позже) и номер LSP, или, скорее, номер фрагмента LSP. Информация, содержащаяся в одном фрагменте LSP, рассматривается как «один блок» во всей сети. Отдельный фрагмент LSP никогда не «рефрагментируется» какой-либо другой IS. Это поле обычно составляет 8 октетов.
Порядковый номер (Sequence Number) описывает версию этого LSP. Порядковый номер гарантирует, что каждая IS в сети имеет одинаковую информацию в своей локальной копии таблицы топологии. Это также гарантирует, что злоумышленник (или «кривая» реализация) не сможет воспроизвести старую информацию для замены новой.
Контрольная сумма (Checksum) гарантирует, что информация, передаваемая во фрагменте LSP, не была изменена во время передачи.
Лавинная рассылка описана на рисунке 4.
На рисунке 4:
А подключен к 2001: db8: 3e8: 100 :: / 64. A создает новый фрагмент, описывающий этот новый достижимый пункт назначения.
A устанавливает флаг SRM на этом фрагменте в сторону B.
Процесс лавинной рассылки в какой-то момент (обычно это вопрос миллисекунд) проверит таблицу топологии и перезальет все записи с установленным флагом SRM.
Как только новая запись будет помещена в свою таблицу топологии, B создаст CSNP, описывающий всю свою базу данных, и отправит его в A.
Получив этот CSNP, A удаляет свой флаг SRM в направлении B.
B проверяет контрольную сумму и сравнивает полученный фрагмент с существующими записями в своей таблице топологии. Поскольку нет другой записи, соответствующей этой системе и идентификатору фрагмента, он поместит новый фрагмент в свою таблицу локальной топологии. Учитывая, что это новый фрагмент, B инициирует процесс лавинной рассылки по направлению к C.
А как насчет удаления информации? Есть три способа удалить информацию из системы IS-IS flooding:
Исходящая IS может создать новый фрагмент без соответствующей информации и с более высоким порядковым номером.
Если весь фрагмент больше не содержит какой-либо действительной информации, исходящая IS может заполнить фрагмент с оставшимся временем жизни (lifetime) равным 0 секунд. Это приводит к тому, что каждая IS в домене лавинной рассылки повторно загружает фрагмент zero age и удаляет его из рассмотрения для будущих вычислений SPF.
Если таймер lifetime во фрагменте истекает в любой IS, фрагмент заполняется лавинной рассылкой с zero age оставшегося времени жизни. Каждая IS, получающая этот фрагмент с zero age, проверяет, что это самая последняя копия фрагмента (на основе порядкового номера), устанавливает оставшееся время жизни для своей локальной копии фрагмента на ноль секунд и повторно загружает фрагмент. Это называется удалением фрагмента из сети.
Когда IS отправляет CNSP в ответ на полученный фрагмент, она фактически проверяет всю базу данных, а не только один полученный фрагмент. Каждый раз, когда фрагмент лавинно рассылается по сети, вся база данных проверяется между каждой парой промежуточных систем.
Подведение итогов об IS-IS
IS-IS можно описать как:
Использование лавинной рассылки для синхронизации базы данных в каждой промежуточной системе в flooding domain (протокол состояния канала).
Расчет loop-free -путей с использованием алгоритма SPF Дейкстры.
Изучение доступных пунктов назначения через конфигурацию и локальную информацию (проактивный протокол).
Проверка двусторонней связи при формировании соседей путем переноса списка «замеченных соседей» в своих пакетах приветствия.
Удаление информации из домена лавинной рассылки с помощью комбинации порядковых номеров и полей оставшегося времени жизни (lifetime) в каждом фрагменте.
Проверка MTU каждой линии связи путем заполнения первоначально обмененных пакетов приветствия.
Проверка правильности информации в синхронизированной базе данных с помощью контрольных сумм, периодического перезапуска и описаний базы данных, которыми обмениваются промежуточные системы.
IS-IS - это широко распространенный протокол маршрутизации, который доказал свою работоспособность в широком диапазоне сетевых топологий и эксплуатационных требований.
Периметр сети в традиционном понимании исчез. Доступ к приложениям и цифровым ресурсам организации происходит из разных мест вне стен офиса и контроль за этими доступами становится серьезной проблемой. Дни, когда можно было защитить границы сети, давно прошли. Настало время для новых стратегий безопасности с нулевым доверием - Zero Trust.
Когда цифровым активам компании приходится преодолевать большие расстояния по небезопасным путям Интернета, ставки настолько высоки, что нельзя доверять ничему и никому. Поэтому следует использовать модель сети с нулевым доверием, чтобы постоянно ограничивать доступ всех пользователей ко всем сетевым ресурсам.
В сетях с нулевым доверием любая попытка доступа к ресурсу ограничивается пользователем или устройством, независимо от того, имели ли они ранее доступ к одному и тому же ресурсу. Чтобы получить доступ к ресурсам любой пользователь или устройство всегда должны проходить процесс аутентификации и верификации, даже если они физически находятся в организации. Эти проверки должны быть быстрыми, чтобы политики безопасности не снижали производительность приложений и работу пользователей.
Zero-trust vs. VPN
Модель сети с нулевым доверием заменяет модель VPN, традиционно используемую компаниями для удаленного доступа своих сотрудников к цифровым ресурсам. VPN заменяется, поскольку они имеют основной недостаток, который могут устранить сети с нулевым доверием. В VPN любая уязвимость, которое происходит в зашифрованном канале, соединяющем пользователя с сетью организации, предоставляет потенциальным злоумышленникам неограниченный доступ ко всем ресурсам компании, подключенным к сети.
В старых локальных инфраструктурах VPN работали хорошо, но они создают больше проблем, чем решений в облачных или смешанных инфраструктурах.
Сети с нулевым доверием устраняют этот недостаток VPN, но добавляют потенциальный недостаток: они могут привести к дополнительной сложности с точки зрения реализации и обслуживания, поскольку полномочия должны быть обновлены для всех пользователей, устройств и ресурсов. Это требует дополнительной работы, но взамен ИТ-отделы получают больший контроль над ресурсами и уменьшается плоскость атаки.
К счастью, преимуществами сети с нулевым доверием можно пользоваться без дополнительных усилий по обслуживанию и развертыванию благодаря инструментам, которые автоматизируют и помогают в задачах администрирования сети. Описанные ниже инструменты помогают применять политики нулевого доверия с минимальными усилиями и затратами.
1. Perimeter 81
Perimeter 81 предлагает два подхода к управлению приложениями и сетями организации и обеспечению их безопасности как в облачных, так и локальных средах. Оба подхода начинаются с предложения сетей с нулевым доверием в качестве услуги. Для этого в Perimeter 81 используется программно-определяемая архитектура периметра, которая обеспечивает большую гибкость для новых пользователей и обеспечивает большую видимость сети. Кроме того, сервис совместим с основными поставщиками облачной инфраструктуры.
Доступ к приложениям с нулевым доверием основан на предположении, что каждая компания имеет критически важные приложения и службы, доступ к которым большинству пользователей не требуется. Сервис позволяет создавать политики для конкретных пользователей в зависимости от их ролей, устройств, местоположений и других идентификаторов.
При этом Zero Trust Network Access определяет сегментацию сети организации по зонам доверия, что позволяет создавать пределы доверия, контролирующие поток данных с высоким уровнем детализации. Доверенные зоны состоят из наборов элементов инфраструктуры с ресурсами, которые работают на одном уровне доверия и обеспечивают аналогичную функциональность. Это уменьшает количество каналов связи и минимизирует возможность возникновения угроз.
Служба доступа к сети с нулевым доверием Perimeter 81 обеспечивает полное и централизованное представление сети организации, обеспечивая наименее привилегированный доступ для каждого ресурса. Его функции безопасности соответствуют модели SASE компании Gartner, поскольку безопасность и управление сетью унифицированы на единой платформе.
Две услуги Perimeter 81 включены в схему ценообразования с широким спектром опций. Эти возможности варьируются от базового плана с необходимыми компонентами для обеспечения безопасности сети и управления ею до корпоративного плана, который может неограниченно масштабироваться и обеспечивает специальную поддержку 24/7.
2. ZScaler Private Access
ZScaler Private Access (ZPA) - это облачная сетевая служба с нулевым доверием, которая управляет доступом к частным приложениям организации независимо от того, находятся ли они в собственном центре обработки данных или в общедоступном облаке. Благодаря ZPA приложения полностью невидимы для неавторизованных пользователей.
В ZPA связь между приложениями и пользователями осуществляется в соответствии со стратегией «наизнанку». Вместо расширения сети для подключения пользователей (как это должно быть сделано при использовании VPN), пользователи никогда не находятся внутри сети. Этот подход существенно минимизирует риски, избегая распространения вредоносных программ и рисков перемещения внутри периметра. Кроме того, сфера применения ZPA не ограничивается веб-приложениями, а относится к любому частному приложению.
ZPA использует технологию микро-туннелей, которая позволяет сетевым администраторам сегментировать сеть по приложениям, устраняя необходимость сегментации в сети с помощью межсетевого экрана или списками управления доступом (ACL). В микро-туннелях используется шифрование TLS и пользовательские закрытые ключи, которые усиливают безопасность при доступе к корпоративным приложениям.
Благодаря усовершенствованным API и ML (машинное обучение), ZPA позволяет ИТ-отделам автоматизировать механизмы нулевого доверия, обнаруживая приложения и создавая для них политики доступа, а также автоматически создавая сегментацию для каждой отдельной рабочей нагрузки приложения.
3. Cloudflare Access
Сетевая служба нулевого доверия Cloudflare поддерживается частной сетью с точками доступа, распределенными по всему миру. Это позволяет ИТ-отделам обеспечивать высокоскоростной и безопасный доступ ко всем ресурсам организации - устройствам, сетям и приложениям.
Сервис Cloudflare заменяет традиционные, ориентированные на сеть периметры безопасности, используя вместо этого безопасный доступ на близком расстоянии, обеспечивающий оптимальную скорость распределенных рабочих групп.
Доступ Cloudflare с нулевым доверием управляет общими приложениями в организации, проверяя подлинность пользователей через собственную глобальную сеть. Это позволяет ИТ-менеджерам регистрировать каждое событие и каждую попытку доступа к ресурсу. Кроме того, это упрощает поддержку пользователей и добавление новых пользователей.
С помощью Cloudflare Access организация может поддерживать свои идентификационные данные, поставщиков защиты, состояние устройств, требования к местоположению каждого приложения и даже существующую облачную инфраструктуру. Для контроля идентичности Cloudflare интегрируется с Azure AD, Okta, Ping и устройством с Tanium, Crowdstrike и Carbon Black.
Cloudflare предлагает бесплатную версию своего сервиса, которая предоставляет основные инструменты и позволяет защитить до 50 пользователей и приложений. Для большего числа пользователей или приложений, а также чтобы воспользоваться другми преимуществами, вроде круглосуточной поддержки по телефону и чату, следует выбрать платные версии.
4. Wandera
Сетевое решение Wandera Private Access с нулевым доверием обеспечивает быстрый, простой и безопасный удаленный доступ к приложениям организации, независимо от того, работают ли они в SaaS или развернуты внутри организации. Сервис отличается своей простотой, процедурами установки, которые могут быть выполнены за считанные минуты и не требуют специализированного оборудования, сертификатов или масштабирования.
Wandera Private Access предлагает гибкость распределенным рабочим группам, работающим на разнородных платформах, с управляемыми или личными устройствами (BYOD). Решение обеспечивает видимость доступа к приложениям в реальном времени, идентификацию теневых ИТ-отделов и автоматическое ограничение доступа с зараженных или небезопасных устройств благодаря политике доступа на базе учета рисков.
С помощью Wandera Private Access можно реализовать модели безопасности, ориентированные на идентификацию, гарантируя, что только авторизованные пользователи смогут подключаться к приложениям организации. Использование микротуннелей на основе приложений связывает пользователей только с приложениями, к которым они имеют право доступа. Применение политики безопасности остается согласованным во всех инфраструктурах, будь то облачные приложения, центры обработки данных или приложения SaaS.
Система защиты Wandera работает от интеллектуального механизма обнаружения угроз под названием MI: RIAM. Этот двигатель ежедневно снабжается информацией, предоставляемой 425 миллионами мобильных датчиков, что обеспечивает защиту от самого широкого спектра известных угроз и угроз нулевого дня.
5. Okta
Okta предлагает модель безопасности с нулевым доверием, которая охватывает широкий спектр услуг, включая защиту приложений, серверов и API; унифицированный и безопасный доступ пользователей к интерактивным и облачным приложениям; адаптивная, контекстно-зависимая, многофакторная аутентификация и автоматическое отключение для уменьшения рисков для бесхозных учетных записей.
Универсальная служба каталогов Okta обеспечивает единое консолидированное представление каждого пользователя в организации. Благодаря интеграции групп пользователей с AD и LDAP, а также связям с системами HR, приложениями SaaS и сторонними поставщиками удостоверений, Okta Universal Directory интегрирует всех типов пользователей, будь то сотрудники компании, партнеры, подрядчики или клиенты.
Okta выделяется своей службой защиты API, поскольку API рассматриваются как новая форма теневых ИТ. Управление доступом к API Okta сокращает время планирования и применения политик на основе XML до нескольких минут, облегчая ввод новых API и интеграцию с партнерами для использования API. Механизм политики Okta позволяет внедрять передовые практики в области безопасности API, легко интегрируясь с фреймворками идентификации вроде OAuth. Политики авторизации API создаются на основе приложений, пользовательского контекста и членства в группах для обеспечения доступа к каждому API только нужных пользователей.
Интеграционная сеть Okta позволяет избежать блокировки поставщиков, предоставляя организациям свободу выбора из более чем 7000 встроенных интеграций с облачными и готовыми системами.
6. CrowdStrike Falcon
Решение CrowdStrike Falcon Identity Protection с нулевым доверием быстро останавливает нарушения безопасности из-за скомпрометированных учётных записей, защищая учетные записи всех пользователей, расположений и приложений в организации с помощью политики нулевого доверия.
Программа Falcon Identity Protection направлена на сокращение затрат и рисков и повышение окупаемости инвестиций используемых инструментов за счет снижения требований к инженерным ресурсам и устранения избыточных процессов обеспечения безопасности.
Унифицированный контроль всех учетных записей упрощает реализацию стратегий условного доступа и адаптивной аутентификации, а также обеспечивает более высокий уровень обслуживания пользователей и более широкий охват многофакторной аутентификации (MFA) даже для устаревших систем.
Решение для удаленного доступа CrowdStrike обеспечивает полную видимость активности аутентификации всех учетных записей и конечных точек, предоставляя, среди прочего, данные о местоположении, источнике/назначении, типе входа (учетная запись человека или службы). В свою очередь, он защищает сеть от инсайдерских угроз, таких как устаревшие привилегированные учетные записи, неправильно назначенные учетные записи служб, ненормальное поведение и полномочия, скомпрометированные атаками продвижения внутри периметра.
Благодаря интеграции с существующими решениями по обеспечению безопасности развертывание Falcon Identity Protection осуществляется в минимальные сроки и без усилий. Помимо прямой интеграции с решениями безопасности для критически важных активов, таких как CyberArk и Axonius, CrowdStrike предлагает высокопроизводительные API, которые позволяют компаниям интегрировать практически с любой системой.
Заключение
Новая норма, похоже, останется, и ИТ-администраторам нужно привыкнуть к ней. Удаленная работа будет оставаться повседневной реальностью, и сети организации больше никогда не будут иметь четко определенных границ.
В этом контексте ИТ-администраторы должны как можно скорее внедрить сетевые и прикладные решения с нулевым доверием, если они не хотят подвергать риску самые ценные цифровые активы своих организаций.