По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Хотим рассказать про операционную систему IOS, разработанную компанией Cisco. Cisco IOS или Internetwork Operating System (межсетевая операционная система) это программное обеспечение, которое используется в большинстве коммутаторов и маршрутизаторов Cisco (ранние версии коммутаторов работали на CatOS). IOS включает в себя функции маршрутизации, коммутации, межсетевого взаимодействия и телекоммуникаций, интегрированных в мультизадачную операционную систему.
Не все продукты Cisco используют IOS. Исключения составляют продукты безопасности ASA, которые используют операционную систему Linux и роутеры-маршрутизаторы, которые запускают IOS-XR. Cisco IOS включает в себя ряд различных операционных систем, работающих на различных сетевых устройствах. Существует много различных вариантов Cisco IOS: для коммутаторов, маршрутизаторов и других сетевых устройств Cisco, версии IOS для определенных сетевых устройств, наборы функций IOS, предоставляющие различные пакеты функций и сервисов.
Сам файл IOS имеет размер в несколько мегабайт и хранится в полупостоянной области памяти под названием flash. Флэш-память обеспечивает энергонезависимое хранилище. Это означает, что содержимое памяти не теряется, когда устройство теряет питание. Во многих устройствах Cisco IOS копируется из флэш-памяти в оперативное запоминающее устройство ОЗУ (RAM), когда устройство включено, затем IOS запускается из ОЗУ, когда устройство работает. ОЗУ имеет множество функций, включая хранение данных, которые используются устройством для поддержки сетевых операций. Работа IOS в ОЗУ повышает производительность устройства, однако ОЗУ считается энергозависимой памятью, поскольку данные теряются во время цикла питания. Цикл питания - это когда устройство намеренно или случайно отключается, а затем снова включается.
Управление устройствами с IOS происходит при помощи интерфейса командной строки (CLI), при подключении при помощи консольного кабеля, по Telnet, SSH либо при помощи AUX порта.
Названия версий Cisco IOS состоят из трех чисел, и нескольких символов a.b(c.d)e, где:
a – номер основной версии
b – номер младшей версии (незначительные изменения)
c – порядковый номер релиза
d – промежуточный номер сборки
e (ноль, одна или две буквы) – идентификатор последовательности выпуска программного обеспечения, такой как none (который обозначает основную линию), T (Technology), E (Enterprise), S (Service provider), XA специальный функционал, XB как другой специальный функционал и т. д.
Rebuild – часто ребилды выпускаются чтобы исправить одну конкретную проблему или уязвимость для данной версии IOS. Ребилды производятся либо для быстрого устранения проблемы, либо для удовлетворения потребностей клиентов, которые не хотят обновляться до более поздней крупной версии, поскольку они могут использовать критическую инфраструктуру на своих устройствах и, следовательно, предпочитают свести к минимуму изменения и риск.
Interim release – промежуточные выпуски, которые обычно производятся на еженедельной основе и образуют срез текущих наработок в области развития.
Maintenance release – протестированные версии, которые включают в себя усовершенствования и исправления ошибок. Компания Cisco рекомендует, по возможности, обновлять ПО до версии Maintenance.
Стадии развития:
Early Deployment (ED) – ранее развертывание, вводятся новые функции и платформы.
Limited Deployment (LD) – первоначальная лимитированная развертка, включают в себя исправления ошибок.
General Deployment (GD) – общее развертывание ОС, происходит тестирование, доработка и подготовка к выпуску окончательной версии. Такие выпуски, как правило, стабильны на всех платформах
Maintenance Deployment (MD) – эти выпуски используются для дополнительной поддержки, исправлений ошибок и постоянного обслуживания программного обеспечения.
Большинство устройств Cisco, которые используют IOS, также имеют один или несколько «наборов функций» или «пакетов» - Feature Set. Например, выпуски Cisco IOS, предназначенные для использования на коммутаторах Catalyst, доступны как «стандартные» версии (обеспечивающие только базовую IP-маршрутизацию), «расширенные» версии, которые предоставляют полную поддержку маршрутизации IPv4 и версии «расширенных IP-сервисов», которые предоставляют расширенные функции, а также поддержку IPv6.
Каждый отдельный feature set соответствует одной категории услуг помимо базового набора (IP Base – Static Routes, OSPF, RIP, EIGRP. ISIS, BGP, IMGP, PBR, Multicast):
IP-данные (Data – добавляет BFD, IP SLAs, IPX, L2TPv3, Mobile IP, MPLS, SCTP)
Голос (Unified Communications – CUBE, SRST, Voice Gateway, CUCME, DSP, VXML)
Безопасность и VPN (Security — Firewall, SSL VPN, DMVPN, IPS, GET VPN, IPSec)
До сих пор в этой серии статей примеры перераспределения маршрутов, над которыми мы работали, использовали один роутер, выполняющий перераспределение между нашими автономными системами. Однако с точки зрения проекта, глядя на этот роутер понимаем, что это единственная уязвимая точка, то есть точка отказа.
Для избыточности давайте подумаем о добавлении второго роутера для перераспределения между несколькими автономными системами. То, что мы, вероятно, не хотим, чтобы маршрут объявлялся, скажем, из AS1 в AS2, а затем AS2 объявлял тот же самый маршрут обратно в AS1, как показано на рисунке.
Хорошая новость заключается в том, что с настройками по умолчанию, скорее всего не будет проблем. Например, на приведенном выше рисунке роутер CTR2 узнал бы два способа добраться до Сети A. Один из способов — это через OSPF, к которому он подключен. Другой путь был бы через EIGRP AS, через роутер CTR1 и обратно в OSPF AS. Обычно, когда роутер знает, как добраться до сети через два протокола маршрутизации, он сравнивает значения административного расстояния (AD) протоколов маршрутизации и доверяет протоколу маршрутизации с более низким AD. В этом примере, хотя EIGRP AD обычно составляет 90, что более правдоподобно, чем OSPF AD 110, AD EIGRP External route (т. е. маршрута, который возник в другом AS) составляет 170. В результате OSPF-изученный маршрут CTR2 к сети A имеет более низкую AD (т. е. 110), чем AD (т. е. 170) EIGRP-изученного маршрута к сети A. Что в итоге? CTR2 отправляет трафик в Сеть A, отправляя этот трафик в OSPF AS, без необходимости передавать EIGRP AS.
Время от времени, однако, нам потребуется произвести настройки некоторых не дефолтных параметров AD, или же нам понадобятся creative metrics, применяемые к перераспределенным маршрутам. В таких случаях мы подвергаемся риску развития событий, описанных на предыдущем рисунке.
Давайте обсудим, как бороться с такой проблемой. Рассмотрим следующую топологию.
В этой топологии у нас есть две автономные системы, одна из которых работает под управлением OSPF, а другая- под управлением EIGRP. Роутеры CTR1 и CTR2 в настоящее время настроены для выполнения взаимного перераспределения маршрутов между OSPF и EIGRP. Давайте взглянем на таблицы IP-маршрутизации этих магистральных роутеров.
Обратите внимание, в приведенном выше примере, что с точки зрения роутера CTR2, лучший способ добраться до Сети 192.0.2.0 / 30 — это next-hop на следующий IP-адрес 192.0.2.5 (который является роутером OFF1). Это означает, что если бы роутер CTR2 хотел отправить трафик в сеть 192.0.2.0 /30, то этот трафик остался бы в пределах OSPF AS. Интересно, что процесс маршрутизации EIGRP, запущенный на роутере CTR2, также знает, как добраться до Сети 192.0.2.0 / 30 из-за того, что роутер CTR1 перераспределяет этот маршрут в Интересно, что процесс маршрутизации EIGRP, запущенный на роутере CTR2, также знает, как добраться до Сети 192.0.2.0 / 30 из-за того, что роутер CTR1 перераспределяет этот маршрут в EIGRP AS, но этот маршрут считается EIGRP External route. Поскольку EIGRP External route AD 170 больше, чем OSPF AD 110, в OSPF маршрут прописывается в таблице IP-маршрутизации роутера CTR2.
Именно так обычно работает Route redistribution, когда у нас есть несколько роутеров, выполняющих перераспределение маршрутов между двумя автономными системами. Однако, что мы можем сделать, если что-то идет не так, как ожидалось (или как мы хотели)? Как мы можем предотвратить перераспределение маршрута, перераспределенного в AS, из этого AS и обратно в исходное AS, например, в примере, показанном на следующем рисунке.
В приведенном выше примере роутер OFF1 объявляет сеть 192.168.1.0 / 24 роутеру CTR1, который перераспределяет этот маршрут из AS1 в AS2. Роутер OFF2 получает объявление маршрута от роутера CTR1 и отправляет объявление для этого маршрута вниз к роутеру CTR2. Роутер CTR2 затем берет этот недавно изученный маршрут и перераспределяет его от AS2 к AS1, откуда он пришел. Мы, скорее всего, не хотим, чтобы это произошло, потому что это создает неоптимальный маршрут.
Общий подход к решению такой проблемы заключается в использовании route map в сочетании с tag (тегом). В частности, когда маршрут перераспределяется из одного AS в другой, мы можем установить тег на этом маршруте. Затем мы можем настроить все роутеры, выполняющие перераспределение, чтобы блокировать маршрут с этим тегом от перераспределения обратно в его исходный AS, как показано на следующем рисунке.
Обратите внимание, что в приведенной выше топологии, когда маршрут перераспределяется от AS1 к AS2, он получает тег 10. Кроме того, роутер CTR2 имеет инструкцию (настроенную в карте маршрутов), чтобы не перераспределять любые маршруты из AS2 в AS1, которые имеют тег 10. В результате маршрут, первоначально объявленный роутером OFF1 в AS1, никогда не перераспределяется обратно в AS1, тем самым потенциально избегая неоптимального маршрута.
Далее давайте еще раз рассмотрим, как мы можем настроить этот подход к тегированию, используя следующую топологию. В частности, на роутерах CTR1 и CTR2 давайте установим тег 10 на любом маршруте, перераспределяемом из OSPF в EIGRP. Затем, на тех же самых роутерах, мы предотвратим любой маршрут с тегом 10 от перераспределения из EIGRP обратно в OSPF.
Для начала на роутере CTR1 мы создаем карту маршрутов, целью которой является присвоение тегу значения 10.
CTR1 # conf term
CTR1 (config) # route-map TAG10
CTR1 (config-route-map) # set tag 10
CTR1 (config-route-map) #exit
CTR1 (config) #
Обратите внимание, что мы не указали permit как часть инструкции route-map, и мы не указали порядковый номер. Причина в том, что permit — это действие по умолчанию, и карта маршрута TAG10 имела только одну запись.
Далее мы перейдем к роутеру CTR2 и создадим карту маршрутов, которая предотвратит перераспределение любых маршрутов с тегом 10 в OSPF. Кроме того, мы хотим, чтобы роутер CTR2 маркировал маршруты, которые он перераспределяет из OSPF в EIGRP со значением тега 10. Это означает, что мы хотим, чтобы роутер CTR1 предотвратил перераспределение этих маршрутов (со значением тега 10) обратно в OSPF. Итак, пока мы находимся здесь на роутере CTR1, давайте настроим route-map, которая предотвратит Route redistribution со значением тега 10 в OSPF.
CTR1 (config) # route-map DENYTAG10 deny 10
CTR1 (config-route-map) # match tag 10
CTR1 (config-route-map) # exit
CTR1 (config) # route-map DENYTAG10 permit 20
CTR1 (config-route-map) # end
CTR1 #
Эта недавно созданная route-map (DENYTAG10) использует ключевые слова permit и deny, и у нее есть порядковые номера. Порядковый номер 10 используется для запрещения маршрутов с тегом 10. Затем имеем следующий порядковый номер (который мы пронумеровали 20), чтобы разрешить перераспределение всех других маршрутов.
Теперь, когда мы создали наши две карты маршрутов, давайте применим TAG10 route map к команде EIGRP redistribute (к тегу routes, перераспределяемому в EIGRP со значением 10). Кроме того, мы хотим применить DENYTAG10 route map к команде OSPF redistribute (чтобы предотвратить перераспределение маршрутов, помеченных значением 10, обратно в OSPF AS).
CTR1 # conf term
CTR1 (config) # router eigrp 100
CTR1 (config-router) # redistribute ospf 1 route-map TAG10
CTR1 (config-router) # router ospf 1
CTR1 (config-router) # redistribute eigrp 100 subnets route-map DENYTAG10
CTR1 (config-router) # end
CTR1 #
Теперь нам нужно ввести зеркальную конфигурацию на роутере CTR2.
CTR2#conf term
CTR2(config)#route-map TAG10
CTR2(config-route-map) # set tag 10
CTR2(config-route-map) # exit
CTR2(config)#route-map DENYTAG10 deny 10
CTR2(config-route-map) # match tag 10
CTR2(config-route-map) # exit
CTR2(config) # route-map DENYTAG10 permit 20
CTR2(config-route-map) # exit
CTR2(config) # router eigrp 100
CTR2(config-router) # redistribute ospf 1 route-map TAG10
CTR2(config-router) # router ospf 1
CTR2(config-router) # redistribute eigrp 100 subnets route-map DENYTAG10
CTR2(config-router) # end
CTR2#
Просто чтобы убедиться, что наши маршруты помечены, давайте проверим таблицу топологии EIGRP роутера OFF2.
Обратите внимание, что все маршруты, перераспределенные в EIGRP из OSPF, теперь имеют тег 10, и мы сказали роутерам CTR1 и CTR2 не перераспределять эти маршруты обратно в OSPF. Именно так мы можем решить некоторые потенциальные проблемы, возникающие при перераспределении маршрутов.
Дело за малым - прочитайте нашу статью про route redistribution с помощью IPv6.
Предприятия, использующие различные бизнес-приложения, должны поддерживать конфиденциальность данных и предоставлять права доступа в соответствии с ролями пользователей во всей инфраструктуре. Сделать это достаточно сложно. SAML (Security Assertion Markup Language) значительно помогает в этом плане.
Давайте посмотрим, что же это такое и как оно работает, в чем его преимущества, чем оно отличается от SSO, а в чем оно похоже, и как оно помогает в проверке доступа к API для обеспечения максимального уровня безопасности.
Что такое SAML?
Основная работа SAML заключается в том, чтобы позволить IdP (поставщикам удостоверений - identity details providers) делиться учетными данными, связанными с аутентификацией, с соответствующими органами. Это открытый стандарт, который позволяет предоставить унифицированный доступ для всех видов приложений без ущерба для безопасности данных.
Вот еще несколько фактов, которые вы должны знать о SAML:
Он использует XML для завершения стандартного соединения между IdP и поставщиками услуг для обеспечения надежной связи.
Процесс аутентификации SAML подтверждает личность конечного пользователя, а авторизация SAML определяет, какие ресурсы должны быть доступны для пользователя.
Он проверяет SP (поставщиков услуг), IdP (поставщиков удостоверений) и конечных пользователей, если пользователь имеет право на требуемое действие.
Это стандарт OASIS.
Обеспечивает безопасный обмен данными.
Он поддерживает активацию SSO. Однако данная процедура требует подключения к внешнему поставщику удостоверений и совместного с ним использования XML-токенов.
Кратко о SSO (Single Sign-on – система однократного входа)
SSO считается одним из самых эффективных механизмов аутентификации и объединяет несколько экранов входа. Это значит, что вам не нужно самостоятельно входить в систему в своих приложениях. Вместо этого для приложений SaaS (Software as a Service) будет работать всего один набор данных для входа для всех ваших учетных записей.
Это обеспечивает более быстрый доступ к приложению, делает его более простым и подконтрольным. Это является ключевым аспектом IAM-стратегий компаний, стремящихся к беспрепятственной проверке доступа к приложениям и наилучшей реализации безопасности.
Включение SSO дает следующие возможности:
Надежные пароли, так как нет необходимости создавать несколько схожих паролей. Достаточно иметь один сложный и надежный пароль.
Пользователям не нужно запоминать различные пароли.
Простое использование MFA (Многофакторная аутентификация), которое проверяет несколько факторов, так как его активация в одной точке обеспечивает защиту различных приложений.
Политика быстрого повторного ввода пароля, поскольку у администраторов есть единственная точка применения политики.
Удобное внутренне управление учетными данными, поскольку SSO хранит пароли пользователей внутри и предоставляет IT-специалистам гораздо больший контроль над базой данных.
Мгновенное восстановление пароля пользователя, поскольку IT-команда должна работать над восстановлением одного пароля.
Аутентификация SAML – пошагово
Давайте рассмотрим всю процедуру в нескольких шагах.
Прежде всего, служба идентификации передает входные данные, связанные со входом пользователя в систему, поставщику услуг. Для бесперебойной передачи параметров SAML поставщикам услуг каждый конечный пользователь обязан один раз войти в систему через SSO.
Затем, SP связывается с IdP для подтверждения достоверности запроса. Этот процесс также требует предоставления согласия на настройку системы однократного входа SAML. Это гарантирует то, что для проверки личности и авторизации пользователя/запроса используются одни и те же параметры SAML.
Преимущества SAML
Данный подход имеет стандартный формат, поэтому он предоставляет предприятиям открытый подход, не зависящий от совместимости платформ и реализаций поставщиков.
Он использует слабосвязанные каталоги, что означает, что нет необходимости хранить и синхронизировать пользовательские данные с локальными каталогами.
Так как он поддерживает SSO, то конечные пользователи получат доступ к приложениям.
SAML позволяет предприятиям повторно использовать интеграции для регистрации/входа, сохраняя при этом тот же уровень безопасности. Это значительно сокращает расходы на управление аккаунтом.
Обязанность обслуживания удостоверений пользователей переносится на IdP, когда работает SAML. Это освобождает поставщиков услуг от лишних проблем, связанных с регистрацией и входом в систему.
Что такое SAML Assertion?
Выражаясь простым языком, это документ в формате XML, который содержит в себе информацию о статусе авторизации пользователя. Эта информация предоставляется IdP поставщику услуг.
Есть утверждения трех типов:
Authentication – это проверка личности пользователя, связанных с ней методов и сведения об отслеживании продолжительности сеанса.
Assigned обеспечивает успешную передачу SAML-токенов поставщику услуг. IdP и SP используют одни и те же атрибуты для подтверждения личности создателя запроса.
И последнее, утверждение типа Authorization-decision объясняет, где пользователю предоставляется доступ в соответствии с его запросом. Если будет отказано в доступе, то также будет предоставлена подробно описанная причина этого отказа.
Пример SAML
Ниже приведен самый простой пример того, как SAML обрабатывает свои операции:
Пусть конечный пользователь по имени Джон пытается получить доступ к бизнес-приложению в служебных целях.
Джон начинает сеанс с SSO и завершает часть процедуры проверки личности.
Zoho CRM запрашивает у IdP информацию о пользователе для подтверждения.
Программное средство SaaS получает доступ к результатам для завершения этапа проверки полномочий.
IdP отвечает по этому запросу в формате SAML. На нем будут цифровые подписи Джона. На основании сходства между идентифицированными данными, которые предоставил Джон и IdP, в ответном сообщении могут содержаться и другие сведения.
Программное средство SaaS получает ответ и предоставляет доступ или отказывает в доступе в соответствии с инструкциями IdP.
Если доступ был разрешен, то Джон может использовать свою учетную запись Zoho.
SAML vs SSO
SAML помогает в проверке личности пользователя и делает возможным использование системы однократного входа (SSO). SSO может существовать отдельно и позволяет конечным пользователям использовать различные приложения с унифицированными данными для входа. SSO может задействовать стандартные протоколы SAML при обмене информацией, поскольку у него нет собственным специальных протоколов. Помимо этого, он может использовать сторонние протоколы, такие как OpenID, для эффективной междоменной проверки личности пользователя. SAML имеет же широкий спектр собственных протоколов.
SAML vs oAuth2
Из-за сходства основного назначения SAML 2.0 и oAuth 2.0 часто принимают за одно и то же программное средство. Хотя они и имеют некоторое сходство, но они также имеют и различия в некоторых аспектах.
Сходства
И то, и другое необходимо для обеспечения безопасного взаимодействия приложений.
Оба поддерживают простое управление доступом и быструю интеграцию.
Различия
oAuth 2.0 больше уделяет внимание на авторизацию, тогда как SAML отдает приоритет аутентификации.
SAML основан на XML, а oAuth 2.0 – на JSON.
SAML поддерживает данные сеанса с помощью файлов cookie, в то время как oAuth использует вызовы API.
Аутентификация API с помощью SAML
Несмотря на то, что одним из самых распространенных вариантов применения SAML является поддержка проверка личности пользователя и включение SSO, он также может оказаться полезным для проверки подлинности запроса в API. Проверка прав доступа пользователя для проверки подлинности запроса является ключевой с точки зрения безопасности API и может быть проведена путем отправки SAML-запроса, который в свою очередь должен предусматривать следующее:
SAML подготавливает запрос аутентификации API на основе API-интерфейса.
Запрос должен содержать SAML-сообщение, которое может поддерживать процесс SSO, автоматически инициируемый IdP.
Очень важно, чтобы сообщение SAML-запроса основывалось на закодированном XML-документе с корневым элементом <Response>.
Тело запроса должно содержать текстовое наполнение, идентификаторы и область. Первые два аспекта являются обязательными, третий – нет.
Ответ SAML включает в себя access_token (маркер SAML, предоставляющий или запрещающий доступ), username (имя пользователя), expires_in, refresh_token и realm (область).
Заключение
SAML и SSO тесно связаны друг с другом. Это критически важно для обеспечения безопасности данных без каких-либо компромиссов. Надеюсь, эта статья поможет вам разобраться в теме и больше узнать об этих двух программных средствах.