Green-sell.info

Новые технологии
2 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Access control что это

Что такое ACL и как его настраивать

В этой статье речь пойдёт об списках аксес листах (списки листов доступа, ACL, NACL, access lists, access control list — все эти слова — синонимы, пусть вас не пугает их разнообразие). Далее в статье, для краткости я буду пользоваться термином ACL.

В этой статье мы поговорим об общих принципах создания ACL, о применении ACL на интерфейсах, о правилах просмотра ACL. Конкретно же о создании самих ACL рассказывается в статьях «Создание стандартного ACL», и «Создание расширенного ACL». В любом случае, рекомендую начать изучение с этой статьи, чтобы было понятно, о чём вообще идёт речь.

Итак, ACL (access control list) — это строго говоря, механизм для выбора из всего потока трафика какой-то части, по заданным критериям. Например, через маршрутизатор проходит множество пакетов, и вот такой ACL выбирает из множества только те пакеты, которые идут из подсети 192.168.1.0/24:

Что дальше делать с этим трафиком — пока неизвестно. Например, трафик, попавший под ACL может заворачиваться в VPN тоннель, или, подвергаться трансляции адресов (NAT). В курсе CCNA рассматривается два способа использования ACL: основной — это фильтрация трафика, второй — использование ACL при настройке NAT. Важно следующее: не имеет значения, где и для каких целей мы будем использовать ACL, правила написания ACL от этого не меняются. Кроме того, если мы только создали ACL, то он пока ни на что не влияет. ACL — это просто несколько неработающих строчек в конфиге, пока мы его не применим, например, на интерфейс, для фильтрации трафика.

Типы ACL

ACL-и бывают двух видов: стандартные и расширенные. Стандартные позволяют отфильтровывать трафик только по одному критерию: адрес отправителя, в CCNA рассматривается конкретно только ip адрес отправителя. Согласитесь, сильно много не нафильтруешь по такому признаку. Можно, например, поставить на выходе из нашей сети такой ACL:

Этот ACL будет разрешать выход в интернет только с перечисленных в нём трёх ip адресов (для такой задачи, как вы видите, нам хватило стандартного ACL).

Расширенный ACL позволяет фильтровать трафик по большому количеству параметров:

  1. Адрес отправителя
  2. Адрес получателя
  3. TCP/UDP порт отправителя
  4. TCP/UDP порт получателя
  5. Протоколу, завёрнутому в ip (отфильтровать только tcp, только udp, только icmp, только gre и т.п.)
  6. Типу трафика для данного протокола (например, для icmp отфильтровать только icmp-reply).
  7. Отделить TCP трафик, идущий в рамках установленной TCP сессии от TCP сегментов, которые только устанавливают соединение. Подробнее об этом можно прочитать в статье «Что делает established в ACL»
  8. И др.

Возможности расширенных ACL богаче стандартных, кроме того, они могут расширяться дополнительными технологиями:

  • Dynamic ACL — ACL, в котором некоторые строчки до поры до времени не работают, но когда администратор подключается к маршрутизатору по telnet-у, эти строчки включаются, то есть администратор может оставить для себя «дыру» в безопасности для отладки или выхода в сеть.
  • Reflexive ACL — зеркальные списки контроля доступа, позволяют запоминать, кто обращался из нашей сети наружу (с каких адресов, с каких портов, на какие адреса, на какие порты) и автоматически формировать зеркальный ACL, который будет пропускать обратный трафик извне вовнутрь только в том случае, если изнутри было обращение к данному ресурсу. Подробнее об этом можно прочесть в статье «Reflexive ACL — настройка и пример работы зеркальных списков контроля доступа»
  • TimeBased ACL, как видно из названия, это ACL, у которых некоторые строчки срабатывают только в какое-то время. Например, с помощью таких ACL легко настроить, чтобы в офисе доступ в интернет был только в рабочее время.

Все ACL (и стандартные, и расширенные) можно задавать по разному: именованным и нумерованным способом. Первый предпочтительнее, так как позволяет затем редактировать ACL, в случае же использования нумерованного способа, ACL можно только удалить целиком и заново создать, либо дописать очередную строчку в конец.

Порядок просмотра ACL

Итак, что из себя представляет ACL и как трафик проверяется на соответствтие?

ACL — это набор правил. Каждое правило состоит из действия (permit, deny) и критерия (для стандартных ACL — ip адрес отправителя, для расширенных — множество критериев). Рассмотрим такой пример стандартного нумерованного ACL:

Этот ACL запрещает доступ для всей сети 192.168.1.0/24 кроме хоста 192.168.1.1 и разрешает доступ для всех остальных сетей. Как проверяется трафик на соответствие ACL? Построчно. То есть, приходит, например, пакет с адреса 192.168.2.2 на роутер, а на том интерфейсе через который он пришел стоит на вход указанный выше ACL, вот построчно Ip адрес отправителя сверяется с данным ACL, что важно — до первого совпадения. Как только пакет совпадёт с какой-то из строк, сработает действие (permit — пропустить пакет либо deny — уничтожить пакет) и дальше никаких проверок по оставшимся строчкам проводиться не будет. Если все строчки пройдены, а пакет так и не попал ни под одно из правил, то он по умолчанию уничтожается. В нашем случае, в примере выше любой пакет подходит под третью строчку, так как там вместо адреса стоит слово «any», означающее, что любой адрес подойдёт. Таким образом, приведённый ACL можно читать так:

  • Если пакет пришёл с адреса 192.168.1.1, то его надо сразу же пропустить и не делать больше никаких проверок в этом ACL;
  • В противном случае, если пакет пришел из сети 192.168.1.0 (кроме адреса 192.168.1.1, с которым мы уже разобрались строчкой выше), то пакет надо уничтожить и опять же, на этом закончить просмотр ACL, не переходить к следующему шагу;
  • Если пакет не попал под первые два правила. То есть он не с адреса 192.168.1.1, да и вообще, не из сети 192.168.1.0, то он всегда попадает под правило permit any, то есть, пакет надо пропустить дальше — пусть идёт.

Очень важно понимать приведённый выше порядок просмотра строк в ACL, он един для всех типов ACL (не только для стандартного). Кроме того, из этого порядка следует очевидное правило: «В ACL-е должны идти наиболее специфичные, узкие, точные строчки вначале и наиболее абстрактные, общие — в конце». Подумайте сами, если бы предыдущий пример был бы отсортирован в обратном порядке:

То по нашему же предыдущему алгоритму, обходился бы он так:

  • Проверяем первую строчку, если пакет из любой сети (any) то его надо пропустить и просмотр дальше прекратить.

Точка. На этом просмотр такого списка будет завершён и совершенно неважно, что мы напишем на второй, третьей и далее строчках, так как весь трафик попадает под действие первой и пропускается, на чём процесс обхода ACL и завершается.

Применение ACL

ACL применяется для разных целей, но основная цель, для которой он используется в CCNA — фильтрация трафика на интерфейсе. Для этого надо сначала создать стандартный или расширенный ACL. Если ACL именованный, то у него есть имя, которое мы и укажем на интерфейсе, если нумерованный — то номер. Чтобы сделать это, заходим на интерфейс и пишем команду ip access-group, например, так:

В этом примере мы применили ACL с именем MY_ACLS_NAME наинтерфейсе Fa0/0 на весь входящий трафик (о чем говорит слово in) если бы мы неписали out — то фильтровался бы исходящий трафик.

Люди часто путаются с направлениями. Например, есть сеть, подключенная к маршрутизатору и стоит задача запретить входящий в эту сеть трафик. Так вот, в данном случае этот входящий трафик фильтруется применением ACL на out, то есть на выход. Всё просто, чтобы не запутаться, надо представить себя на месте маршрутизатора. Понятно, что если трафик входит в какую-то сеть, то он при том выходит из маршрутизатора и с точки зрения роутера, такой трафик исходящий.

Вообще, на один интерфейс можно навесить более одного ACL, но при условии, что у них будет отличаться направление, либо, протокол (есть ведь ещё IPX ACL AppleTalk ACL). Впрочем, для CCNA это не имеет значения, так как в нём речь идёт только об IP ACL. Таким образом, если ограничиваться только IP, то на каждый интерфейс можно навесить не более двух ACL: один на in, второй — на out.

Где лучше применять ACL? Вопрос, на самом деле, не тривиальный и студенты без должного опыта часто дают на него неправильный ответ. Рассмотрим пример: Дана топология, надо запретить доступ с компьютера в сеть ноутбука двумя способами по очереди (сначала с помощью стандартного, затем с помощью расширенного ACL).

Подумайте над этим немного. Здравый смысл и рекомендация от cisco подталкивают нас к следующему правилу: «Стандартный ACL приходится размещать максимально близко к получателю трафика». Действительно, ведь с помощью стандартного ACL мы можем смотреть только на адрес отправителя и не знаем, куда именно этот трафик идёт. Поэтом, если мы разместим запрещающий доступ с Ip адреса компьютера список, например, на R1 на вход на Fa0/0, то мы сможем запретить или разрешить только весь трафик с компьютера сразу, то есть во все сети, а не только в сеть ноутбука. Поэтому, придётся ставить такой ACL максимально близко к получателю трафика, а именно, на R4 на выход из интерфейса Fa0/1. Если пакет дошел до сюда и собирается выйти через Fa0/1, значит он точно собирается в сеть ноутбука. Теперь с помощью стандартного ACL мы можем отсечь трафик, идущий от компьютера.

Если мы хотим использовать расширенный ACL, то мы, в принципе, можем его поставить где угодно, но разумнее всего его ставить максимально близко к отправителю трафика, то есть, в нашем примере, на Fa0/0 на R1 на вход. Действительно, если мы можем смотреть в расширенном ACL-е адрес получателя, то давайте сделаем это максимально быстро и если пакет идёт из компьютера в сеть ноутбука, то уничтожим его сразу же на входе в Fa0/0, чтобы дальше не нагружать сеть передачей этого пакета.

Читать еще:  Get access to

Таким образом, у нас есть небольшое правило, которое может упростить жизнь: «Стандартный ACL ставится максимально близко к получателю трафика, расширенный — максимально близко к источнику трафика». Правило не всегда супер эффективно, иногда надо и голову включать, но для начала оно неплохо работает. Лучше всего выбирать место изначально по этому правилу, а затем подумать над тем, откуда трафик идёт и как можно улучшить размещение ACL.

ACL можно применять не только для фильтрации трафика, но и для ограничения адресов, с которых можно подключиться к роутеру по telnet или ssh. Эта полезная функция описывается в отдельной статье «Ограничение доступа к маршрутизатору по telnet или ssh с помощью ACL»

ACL: СПИСКИ КОНТРОЛЯ ДОСТУПА И ИХ ПРИМЕНЕНИЕ В ОРГАНИЗАЦИИ СЕТЕЙ

студент кафедры ИКБиСП Московского Технологического Университета,

студент кафедры ИКБиСП Московского Технологического Университета,

Аннотация. Один из важнейших навыков сетевого администратора — управление списками контроля доступа (ACL-списками). Списки контроля доступа (ACL) обеспечивают безопасность сети.

Специалисты по проектированию сетей используют межсетевые экраны для обеспечения защиты сети от несанкционированного использования. Межсетевые экраны или брандмауэры представляют собой аппаратные или программные решения, направленные на повышение степени защищенности сети. Рассмотрим в качестве примера заблокированную дверь помещения внутри здания. Благодаря блокировке в помещение могут войти только авторизованные лица, имеющие ключ или карту доступа. Аналогичным образом межсетевой экран фильтрует неавторизованные или потенциально опасные пакеты, предотвращая их проникновение в сеть.

Ключевые слова: ACL-список, контроль, безопасность, сеть.

Что такое ACL-список?

ACL-список — это ряд команд IOS, определяющих, пересылает ли маршрутизатор пакеты или сбрасывает их, исходя из информации в заголовке пакета. ACL-списки являются одной из наиболее используемых функций операционной системы Cisco IOS.

В зависимости от конфигурации ACL-списки выполняют следующие задачи:

  • Ограничение сетевого трафика для повышения производительности сети. Например, если корпоративная политика запрещает видео трафик в сети, необходимо настроить и применить ACL-списки, блокирующие данный тип трафика. Подобные меры значительно снижают нагрузку на сеть и повышают ее производительность.
  • Вторая задача ACL-списков — управление потоком трафика. При помощи списков контроля доступа (ACL) можно ограничить доставку маршрутных обновлений, чтобы гарантировать достоверность источников таких обновлений.
  • Списки контроля доступа обеспечивают базовый уровень безопасности в отношении доступа к сети. ACL-списки могут открыть доступ к части сети одному узлу и закрыть его для других узлов. Например, доступ к сети отдела кадров может быть ограничен и разрешен только авторизованным пользователям.
  • ACL-списки осуществляют фильтрацию трафика на основе типа трафика. Например, ACL-список может разрешать трафик электронной почты, но при этом блокировать весь трафик протокола Telnet.
  • Списки контроля доступа осуществляют сортировку узлов в целях разрешения или запрета доступа к сетевым службам. С помощью ACL-списков можно разрешать или запрещать доступ к определенным типам файлов, например, FTP или HTTP.

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

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

Фильтрации пакетов.

Список контроля доступа ACL — это последовательный список разрешающих или запрещающих операторов, называемых записями контроля доступа (ACE). Записи контроля доступа также часто называют правилами ACL-списка. При прохождении сетевого трафика через интерфейс, где действует список контроля доступа (ACL), маршрутизатор последовательно сопоставляет информацию из пакета с каждой записью в списке контроля доступа на предмет соответствия. Этот процесс называется фильтрацией пакетов.

Фильтрация пакетов обеспечивает контроль доступа к сети на основе анализа входящих и исходящих пакетов с последующей переадресацией или отбрасыванием этих пакетов согласно заданным критериям. Как показано на рисунке, фильтрация пакетов может происходить на уровнях 3 и 4. Стандартные списки контроля доступа (ACL) обеспечивают фильтрацию только на уровне 3. Расширенные списки контроля доступа (ACL) обеспечивают фильтрацию на уровнях 3 и 4.

Рисунок 2. Фильтрация пакетов

В каждой записи стандартного списка контроля доступа (ACL) IPv4 содержится критерий фильтрации, в роли которого выступает IPv4-адрес источника. Если на маршрутизаторе настроен стандартный список контроля доступа (ACL) IPv4, то, получив пакет, такой маршрутизатор извлекает из заголовка пакета IPv4-адрес источника. Далее маршрутизатор последовательно сравнивает адрес с адресом в каждой из записей в списке контроля доступа (ACL), начиная с первой записи. Обнаружив соответствие, маршрутизатор выполняет соответствующую инструкцию — разрешает либо запрещает прохождение пакета. При этом остальные записи в списке контроля доступа (ACL) не анализируются. Если IPv4-адрес источника не соответствует ни одной записи в списке контроля доступа (ACL), такой пакет отбрасывается.

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

Принцип работы списков контроля доступа.

Списки контроля доступа определяют набор правил, обеспечивающих дополнительный контроль над пакетами, которые принимаются интерфейсами, транзитными пакетами, которые передаются через маршрутизатор, а также пакетами, которые отправляются из интерфейсов маршрутизатора. Списки контроля доступа не применяются к пакетам, созданным маршрутизатором.

Как показано на рисунке, можно настроить списки контроля доступа (ACL) для входящего и исходящего трафика.

  • Входящие ACL-списки — входящие пакеты обрабатываются перед отправкой на выходной интерфейс. Входящий ACL-список эффективен, поскольку он сохраняет ресурсы на поиск маршрута, если пакет сбрасывается. Если согласно списку контроля доступа (ACL) прохождение пакета следует разрешить, то этот пакет маршрутизируется. Входные списки контроля доступа (ACL) лучше всего подходят для случаев, когда единственным источником проверяемых пакетов является сеть, подключенная к входному интерфейсу.
  • Исходящие ACL-списки — входящие пакеты маршрутизируются на выходной интерфейс, а затем обрабатываются исходящим списком контроля доступа. Исходящие ACL-списки лучше всего использовать, когда одинаковые фильтры применяются к пакетам, поступающим с множества входящих интерфейсов, перед выходом на тот же выходной интерфейс.

Рисунок 3. Входящие и исходящие ACL-списки

CA Access Control

CA Access Control — система, помогающая организациям защитить свои критически важные серверные ресурсы по всем платформам и операционным системам. CA Access Control гарантирует порядок с доступом к специальным системам, с проводимыми операциями и условиями, при которых этот доступ разрешен.

Критически важные организационные процессы и информация такие, как деловые операции и финансовые записи, базируются на распределенных серверах. Даже при наличии единичной бреши в системе защиты или единичном нарушении обслуживания бизнес рискует понести финансовые потери и испортить отношения с заказчиками. Кроме того, Sarbanes Oxley, HIPAA, PCI, Basel II и другие правила обеспечения секретности и защиты конфиденциальности требуют подтверждения безопасности данных и сервисов. Несоответствие этим правилам может привести к серьезному наказанию — как в финансовом отношении, так и с точки зрения репутации.

CA Access Control обеспечивает централизованное управление привилегиями доступа пользователей, поэтому Ваша организация может:

  • повысить безопасность доступа во всей сети серверов;
  • ввести учет доступа и разделение полномочий;
  • снизить расходы на администрирование и его сложность;
  • поддерживать регулируемую совместимость;
  • обеспечить доступность приложений, баз данных, сетевых серверов и других ресурсов.

CA Access Control предлагает беспрецедентную степень защиты серверной операционной системы. Система предоставляет необходимый уровень обеспечения безопасности на всех платформах, включая детальный контроль доступа, базирующийся на политиках управления, и защищенное аудитирование, играющие существенную роль в обеспечении защиты электронных ресурсов и ее укреплении. Являясь составной частью принятой Computer Associates концепции IT-управления предприятием (EITM), это решение укрепляет возможности предприятия по объединению и упрощению общего IT-управления. CA Access Control регулирует доступ к серверам, обеспечивающим поддержку конфиденциальных бизнес-данных и ответственных сервисов.

Возросшие возможности, обусловленные Интернетом и возросшей мощностью всех серверных платформ, вносят существенный вклад в развитие бизнеса, но не без деловых рисков. Организации должны соблюдать баланс в открытии своих систем для бизнеса и защите своих данных и сервисов от несанкционированного доступа. Под последним понимаются как внутренние, так и внешние атаки и отсутствие контролируемости, что идет в разрез с соблюдением нормативов. CA Access Control предоставляет необходимый уровень обеспечения безопасности и защиты серверов предприятия с высочайшим уровнем защиты доступа к хосту. Наряду с согласованным и надежным периметром безопасности система включает хорошо организованное управление распределенными системами. Применение динамической политики позволяет эффективно идентифицировать данные и сервисы, к которым должны получить доступ пользователи, и предотвращает несанкционированный доступ до возникновения любого их повреждения. Защищенные аудит-журналы фиксируют всю идентификационную информацию, что позволяет эффективно отслеживать активность пользователей или автоматически генерировать сигнал тревоги для инициирования необходимых действий, связанных с незаконным доступом.

CA Access Control гарантирует, что администраторы и приложения получают доступ только к тем ресурсам, которые необходимы для выполнения их рабочих функций, и обеспечивает детальный аудит.

  • Детальный контроль. CA Access Control предоставляет средства контроля индивидуального доступа в систему и регулирует доступ к ресурсам, программам, файлам и процессам посредством набора строгих критериев, включающих: время, метод входа в систему, сетевые атрибуты и программу управления доступом.
  • Ограничения для привилегированного пользователя. CA Access Control гарантирует, что права, связанные с учетными записями привилегированных пользователей — «администратора» для Windows и «root» для UNIX/Linux — могут быть ограничены и переданы другим пользователям. Этот критически важный слой структурирования разрушает расширенный набор возможностей администратора и назначает и присваивает права доступа, основанные на конкретной роли.
  • Делегирование функций администрирования и отслеживаемость. Делегирование прав доступа назначенным системным операторам исключает перемещение привилегий и обеспечивает соответствующее разделение функций.
  • Программное маршрутизирование. Для пользователей, например, операторов, обеспечивающих резервное копирование и менеджеров баз данных, использующих несколько специальных программ для выполнения своих функций, можно обеспечить доступ к этим ресурсам только через специально выделенную программу.

УПРАВЛЕНИЕ НА ОСНОВЕ ПОЛИТИКИ

  • Автоматизированное распространение политики. CA Access Control связывает политики в иерархическую структуру с целью создания всеобъемлющих наборов политик без усложнения управления. Инфраструктура базы данных модели политики автоматически распространяет политики по иерархической структуре серверных узлов. Можно настроить распределение политик в соответствии с потребностями ведения бизнеса, например, путем группирования соответствующих наборов политик по определенным операционным системам, типам серверов или общим приложениям.
  • Многослойное и многоабонентское наследование политик. Наследование политик может осуществляться от многих источников политик управления доступом, основанных на иерархии политик. Эта иерархия включает системные политики, политики приложений и политики управления web-серверами. Изменения в родительской политике автоматически передаются абонентам.
  • Интуитивное управление. Интуитивное управление CA Access Control позволяет легко определять или изменять политики, что означает синхронное изменение управления доступом в соответствии с эволюцией процессов.
  • Подготовка отчетности по отступлению от политик. Иногда может происходить некорректное разворачивание политик из-за проблем с подключением или доступностью конечных точек во время передачи. CA Access Control имеет функцию подготовки отчетов, работа которой основана на сравнении политик, которые должны действовать на конкретной машине, с фактически развернутыми в сети политиками. Эта возможность быстрой идентификации расхождения политик способствует поддержанию постоянного соответствия стандартам соответствия.
  • Собственное управление политиками. CA Access Control может использоваться для контроля безопасности как собственных учетных записей пользователей в среде операционной системы, так и контрольных списков доступа, что значительно снижает необходимость использования двух наборов средств управления.

КРОСС-ПЛАТФОРМЕННАЯ ЗАЩИТА ХОСТОВ

  • Широкий охват различных платформ. Разнообразие серверных платформ, операционных систем и приложений, применяемых на предприятиях, потенциально представляет уязвимость в системе безопасности. Прочность сетевой инфраструктуры определяется ее наиболее слабым звеном. CA Access Control нивелирует различия между платформами и обеспечивает надлежащую защиту всех распределенных серверов, включая Linux, UNIX и Windows.
  • Централизованное администрирование. CA Access Control предоставляет администраторам системы безопасности возможность централизованного управления политиками безопасности, учетными записями и паролями пользователей всех подразделений и на всех платформах. Для управления учетными записями и правами доступа могут использоваться различные интерфейсы, включая веб-интерфейс, графический интерфейс и интерфейс командной строки.
  • Широкая поддержка виртуализации. Организации все чаще внедряют виртуализацию для объединения серверов и снижения общих затрат на эксплуатацию. CA Access Control поддерживает широкий круг платформ виртуализации, включая сервер VMware ESX, Solaris 10 Zones и Linux Xen, обеспечивая согласованное управление безопасностью доступа даже на виртуальных сегментах.

АУДИРОВАНИЕ В СИСТЕМЕ БЕЗОПАСНОСТИ

  • Идентификация по журналу аудита. Журналы аудита в CA Access Control фиксируют все подробности взаимодействия отдельных сотрудников с защищенными ресурсами. Каждая запись фиксирует завершенное действие конкретного пользователя и записывается в отдельный журнал аудита, в котором отслеживаются все действия конкретного пользователя даже после выполнения им операций под чужим именем.
  • Целостность системного журнала. После создания доступ к системным журналам получает только пользователь с правами аудитора, при этом доступ ограничен режимом «только чтение». Это обеспечивает конкретное судебное доказательство потенциальных нарушений безопасности или соответствия стандартам.
  • Маршрутизация системных журналов. Журналы аудита CA Access Control создаются локально, но в случае необходимости могут направляться на центральный узел для исследования или анализа. Пересылка системных журналов с различных источников системы управления доступом от CA на удаленный сервер дополнительно защищает целостность данных.
  • Встроенная защита. CA Access Control имеет встроенные средства защиты от хакерских атак и непрерывно отслеживает протекающие в ней процессы и ведение журналов аудита для обеспечения целостности системы безопасности. Пользователи практически не имеют возможности совершать атаки, вносить изменения или уничтожать базовые сервисы и данные.
  • Интеграция с Центром управления системы безопасности CA (CA SCC). Происходящие в CA Access Control события могут отслеживаться и контролироваться CA SCC и объединяться в полную систему аудита доступа во всей сети, системе безопасности и по всем источникам приложений и действующего аудита.

CA Access Control защищает информационные ресурсы и вводит стандарт безопасности

Возможность минимизации финансовых потерь и сохранения доверия заказчиков определяется способностью системы идентифицировать и контролировать информацию, к которой пользователи могут или не могут получить доступ в ходе их взаимодействия. CA Access Control обеспечивает высочайший уровень защиты доступа к хосту предприятия и снижает нагрузку на администратора по контролю за безопасностью в среде распределенных систем. Нет необходимости определять и управлять правами доступа каждого пользователя по очереди — динамическое управление политиками делает это автоматически. Система гарантирует, что каждый пользователь имеет права доступа только к тем данным и системам, которые необходимы для выполнения его или ее рабочих функций.

Учетные записи пользователей, пароли и политики безопасности могут использоваться на всех управляемых серверах, при этом управление доступом во всей сети осуществляется с единой консоли администратора. Централизованное управление дает возможность администраторам устанавливать защиту на отдельном системном уровне, по всей инфраструктуре или на любом промежуточном уровне. Это позволяет использовать единообразную безопасность для всех серверных сред, при этом помогая контролировать расходы на администрирование. CA Access Control обеспечивает доступность приложений, баз данных и сетевых серверов, предоставляя соответствующий доступ для зарегистрированных пользователей. С помощью этой системы создается надежный периметр безопасности для всей серверной сети, а не просто укрепляются отдельные слабые места. В то же время защищенная, масштабируемая и надежная аудиторская информация помогает обеспечить соответствие стандартам путем документирования взаимодействий каждого пользователя с конкретными системами.

Преимущество решения от CA

CA Access Control составляет часть полного и апробированного решения CA по управлению доступом и идентификацией (IAM), которое помогает обеспечить защиту IT-ресурсов для всех платформ и сред. В этом качестве она позволяет оптимизировать производительность, надежность и эффективность всей IT-среды предприятия. Следующий шаг состоит в тесной интеграции контроля и управления отдельных функций, например, операций, хранения и управления жизненным циклом и техобслуживанием с безопасностью IT-среды. CA Access Control сегодня является ведущим на рынке продуктом по управлению безопасным доступом к хосту.

Описание предыдущей версии eTrust Access Control

Команда iCACLS – управление доступом к файлам и папкам.

Команда iCACLS позволяет отображать или изменять списки управления доступом (Access Control Lists (ACLs) ) к файлам и папкам файловой системы. Утилита iCACLS.EXE является дальнейшим усовершенствованием утилиты управления доступом CACLS.EXE.

Управление доступом к объектам файловой системы NTFS реализуется с использованием специальных записей в таблице MFT (Master File Table). Каждому файлу или папке файловой системы NTFS соответствует запись в таблице MFT, содержащая специальный дескриптор безопасности SD (Security Descriptor). Каждый дескриптор безопасности содержит два списка контроля доступа:

System Access-Control List (SACL) — системный список управления доступом .

Discretionary Access-Control List (DACL) — список управления избирательным доступом.

SACL управляется системой и используется для обеспечения аудита попыток доступа к объектам файловой системы, определяя условия при которых генерируется события безопасности. В операционных системах Windows Vista и более поздних, SACL используется еще и для реализации механизма защиты системы с использованием уровней целостности ( Integrity Level, IL).

DACL — это собственно и есть список управления доступом ACL в обычном понимании. Именно DACL формирует правила, определяющие, кому разрешить доступ к объекту, а кому — запретить.

Каждый список контроля доступа (ACL) представляет собой набор элементов (записей) контроля доступа — Access Control Entries, или ACE) . Записи ACE бывают двух типов (разрешающий и запрещающий доступ), и содержит три поля:


SID
пользователя или группы, к которому применяется данное правило


Вид доступа
, на которое распространяется данное правило


Тип ACE
— разрешающий или запрещающий.

SID — Security ID – уникальный идентификатор, который присваивается каждому пользователю или группе пользователей в момент их создания. Посмотреть примеры SID можно , например с помощью команды WHOAMI /ALL. Как видим, система управления доступом к объектам NTFS оперирует не именами, а идентификаторами SID. Поэтому, например нельзя восстановить доступ к файлам и папкам, существовавший для удаленного из системы пользователя, создав его заново с тем же самым именем – он получит новый SID и правила записей ACE, применяемые к старому идентификатору SID, выполняться не будут.

При определении результатов запросов на доступ к объектам файловой системы NTFS применимы следующие правила:

Если в дескрипторе безопасности отсутствует DACL , то объект считается незащищенным, т.е. все имеют к нему неограниченный доступ.

Если DACL существует, но не содержит ни одного элемента ACE, то доступ к объекту закрыт для всех.

Для того чтобы изменить DACL объекта, пользователь (процесс) должен обладать правом записи в DACL (WRITE_DAC — WDAC). Право записи может быть разрешено или запрещено, с помощью утилиты icalc.exe, но даже если установлен запрет, все равно разрешение на запись имеется хотя бы у одного пользователя владельца файла или папки (поле Owner в дескрипторе безопасности), так как владелец всегда имеет право изменять DAC.

Варианты применения команды iCACLS:


ICACLS имя /save ACL_файл [/T] [/C] [/L] [/Q]
— сохранение DACL для файлов и папок, соответствующих имени, в ACL-файл для последующего использования с командой /restore. Обратите внимание, что метки SACL, владельца и целостности не сохраняются.


ICACLS каталог [/substitute SidOld SidNew [. ]] /restore ACL_файл [/C] [/L] [/Q]
— применение ранее сохраненных DACL к файлам в каталоге.


ICACLS имя /setowner пользователь [/T] [/C] [/L] [/Q]
— смена владельца всех соответствующих имен. Этот параметр не предназначен для принудительной смены владельца; используйте для этой цели программу takeown.exe.


ICACLS имя /findsid Sid [/T] [/C] [/L] [/Q]
— поиск всех соответствующих имен, содержащих ACL с явным упоминанием ИД безопасности.


ICACLS имя /verify [/T] [/C] [/L] [/Q]
— поиск всех файлов с неканоническими ACL или длинами, не соответствующими количеству ACE.


ICACLS имя /reset [/T] [/C] [/L] [/Q]
— замена ACL на унаследованные по умолчанию для всех соответствующих файлов.


ICACLS имя [/grant[:r] Sid:perm[. ]] [/deny Sid:perm [. ]] [/remove[:g|:d]] Sid[. ]] [/T] [/C] [/L] [/Q] [/setintegritylevel Level:policy[. ]]

/grant[:r] Sid:perm — предоставление указанных прав доступа пользователя. С параметром :r эти разрешения заменяют любые ранее предоставленные явные разрешения. Без параметра :r разрешения добавляются к любым ранее предоставленным явным разрешениям.

/deny Sid:perm — явный отзыв указанных прав доступа пользователя. Добавляется ACE явного отзыва для заявленных разрешений с удалением этих же разрешений в любом явном предоставлении.

/remove[:[g|:d]] Sid — удаление всех вхождений ИД безопасности в ACL. С параметром :g удаляются все вхождения предоставленных прав в этом ИД безопасности. С параметром :d удаляются все вхождения отозванных прав в этом ИД безопасности.

/setintegritylevel [(CI)(OI)]уровень — явное добавление ACE уровня целостности ко всем соответствующим файлам. Уровень задается одним из следующих значений:

Уровню могут предшествовать параметры наследования для ACE целостности, применяемые только к каталогам.

Механизм целостности Windows Vista и более поздних версий ОС, расширяет архитектуру безопасности путём определения нового типа элемента списка доступа ACE для представления уровня целостности в дескрипторе безопасности объекта (файла, папки). Новый ACE представляет уровень целостности объекта. Он содержится в системном ACL (SACL), который ранее используемом только для аудита. Уровень целостности также назначается токену безопасности в момент его инициализации. Уровень целостности в токене безопасности представляет уровень целостности (Integrity Level, IL) пользователя (процесса). Уровень целостности в токене сравнивается с уровнем целостности в дескрипторе объекта когда монитор безопасности выполняет проверку доступа. Система ограничивает права доступа в зависимости от того выше или ниже уровень целостности субъекта по отношению к объекту, а также в зависимости от флагов политики целостности в соответствующей ACE объекта. Уровни целостности (IL) представлены идентификаторами безопасности (SID), которые представляют также пользователей и группы, уровень которых закодирован в относительном идентификаторе (RID) идентификатора SID. Наиболее распространенные уровни целостности:

SID = S-1-16-4096 RID=0x1000 — уровень Low (Низкий обязательный уровень)

SID= S-1-16-8192 RID=0x2000 – уровень Medium (Средний обязательный уровень)

SID= S-1-16-12288 RID=0x3000 – уровень High (Высокий обязательный уровень)

SID= S-1-16-16384 RID=0x4000 – уровень системы (Обязательный уровень системы).

e — включение наследования

d — отключение наследования и копирование ACE

r — удаление всех унаследованных ACE

ИД безопасности могут быть в числовой форме (SID), либо в форме понятного имени (username). Если задана числовая форма, добавьте * в начало ИД безопасности, например — *S-1-1-0. Параметры командной строки iCACLS:

/T — операция выполняется для всех соответствующих файлов и каталогов, расположенных в заданном каталоге.

/C — выполнение операции продолжается при любых файловых ошибках. Сообщения об ошибках по-прежнему выводятся на экран.

/L — операция выполняется над самой символьной ссылкой, а не над ее целевым объектом.

/Q — утилита ICACLS подавляет сообщения об успешном выполнении.

Утилита ICACLS сохраняет канонический порядок записей ACE:

разрешение — это маска разрешения, которая может задаваться в одной из двух форм:


последовательность простых прав:

N — доступ отсутствует

F — полный доступ

M — доступ на изменение

RX — доступ на чтение и выполнение

R — доступ только на чтение

W — доступ только на запись

D — доступ на удаление


список
отдельных прав через запятую в скобках:

DE — удаление
RC — чтение
WDAC — запись DAC
WO — смена владельца
S — синхронизация
AS — доступ к безопасности системы
MA — максимально возможный
GR — общее чтение
GW — общая запись
GE — общее выполнение
GA — все общие
RD — чтение данных, перечисление содержимого папки
WD — запись данных, добавление файлов
AD — добавление данных и вложенных каталогов
REA — чтение дополнительных атрибутов
WEA — запись дополнительных атрибутов
X — выполнение файлов и обзор папок
DC — удаление вложенных объектов
RA — чтение атрибутов
WA — запись атрибутов

Права наследования могут предшествовать любой форме и применяются только к каталогам:

(OI) — наследование объектами

(CI) — наследование контейнерами

(IO) — только наследование

(NP) — запрет на распространение наследования

(I) — наследование разрешений от родительского контейнера

Примеры использования iCACLS:

icacls — запуск без ключей используется для получения краткой справки по использованию команды.

icacls C:Users — отобразить список управления доступом для папки C:Users. Пример отображаемой информации:

C:Users NT AUTHORITYсистема:(OI)(CI)(F)
BUILTINАдминистраторы:(OI)(CI)(F)
BUILTINПользователи:(RX)
BUILTINПользователи:(OI)(CI)(IO)(GR,GE)
Все:(RX)
Все:(OI)(CI)(IO)(GR,GE)

Успешно обработано 1 файлов; не удалось обработать 0 файлов

icacls c:windows* /save D:win7.acl /T — сохранение ACL для всех файлов в каталоге c:windows и его подкаталогах в ACL-файл D:win7.acl. Сохраненные списки ACL позволят восстановить управление доступом к файлам и каталогам в исходное состояние, поэтому, прежде чем выполнять какие-либо изменения, желательно иметь файл сохраненных списков ACL.

Пример данных сохраненных списков доступа ACL:

В тех случаях, когда при выполнении команды iCACLS возникает ошибка, вызванная отказом в доступе к обрабатываемому объекту, можно продолжить выполнение команды, если задан параметр /C:

icacls «C:System Volume Information*» /save D:SVI-C.acl /T /C — сохранение списков управления доступом ACL для всех файлов и подкаталогов каталога C:System Volume Information с продолжением обработки в случае возникновения ошибки. По результатам обработки отображается сообщение о количестве успешно, и не успешно, обработанных файлов.

Для восстановления доступа к файлам и папкам используется параметр /restore:

icacls c:windows /restore D:win7.acl — восстановление списков контроля доступа к файлам и папкам каталога c:windows из ранее сохраненного ACL-файла D:win7.acl.

XMLHttpRequest: кросс-доменные запросы

Материал на этой странице устарел, поэтому скрыт из оглавления сайта.

Более новая информация по этой теме находится на странице https://learn.javascript.ru/fetch-crossorigin.

Обычно запрос XMLHttpRequest может делать запрос только в рамках текущего сайта. При попытке использовать другой домен/порт/протокол – браузер выдаёт ошибку.

Существует современный стандарт XMLHttpRequest, он ещё в состоянии черновика, но предусматривает кросс-доменные запросы и многое другое.

Большинство возможностей этого стандарта уже поддерживаются всеми браузерами, но увы, не в IE9-.

Впрочем, частично кросс-доменные запросы поддерживаются, начиная с IE8, только вместо XMLHttpRequest нужно использовать объект XDomainRequest.

Кросс-доменные запросы

Разберём кросс-доменные запросы на примере кода:

  1. Мы создаём XMLHttpRequest и проверяем, поддерживает ли он событие onload . Если нет, то это старый XMLHttpRequest , значит это IE8,9, и используем XDomainRequest .
  2. Запрос на другой домен отсылается просто указанием соответствующего URL в open . Он обязательно должен быть асинхронным, в остальном – никаких особенностей.

Контроль безопасности

Кросс-доменные запросы проходят специальный контроль безопасности, цель которого – не дать злым хакерам™ завоевать интернет.

Серьёзно. Разработчики стандарта предусмотрели все заслоны, чтобы «злой хакер» не смог, воспользовавшись новым стандартом, сделать что-то принципиально отличное от того, что и так мог раньше и, таким образом, «сломать» какой-нибудь сервер, работающий по-старому стандарту и не ожидающий ничего принципиально нового.

Давайте, на минуточку, вообразим, что появился стандарт, который даёт, без ограничений, возможность делать любой странице HTTP-запросы куда угодно, какие угодно.

Как сможет этим воспользоваться злой хакер?

Он сделает свой сайт, например http://evilhacker.com и заманит туда посетителя (а может посетитель попадёт на «злонамеренную» страницу и по ошибке – не так важно).

Когда посетитель зайдёт на http://evilhacker.com , он автоматически запустит JS-скрипт на странице. Этот скрипт сделает HTTP-запрос на почтовый сервер, к примеру, http://gmail.com . А ведь обычно HTTP-запросы идут с куками посетителя и другими авторизующими заголовками.

Поэтому хакер сможет написать на http://evilhacker.com код, который, сделав GET-запрос на http://gmail.com , получит информацию из почтового ящика посетителя. Проанализирует её, сделает ещё пачку POST-запросов для отправки писем от имени посетителя. Затем настанет очередь онлайн-банка и так далее.

Спецификация CORS налагает специальные ограничения на запросы, которые призваны не допустить подобного апокалипсиса.

Запросы в ней делятся на два вида.

Простыми считаются запросы, если они удовлетворяют следующим двум условиям:

  1. Простой метод: GET, POST или HEAD
  2. Простые заголовки – только из списка:
  • Accept
  • Accept-Language
  • Content-Language
  • Content-Type со значением application/x-www-form-urlencoded , multipart/form-data или text/plain .

«Непростыми» считаются все остальные, например, запрос с методом PUT или с заголовком Authorization не подходит под ограничения выше.

Принципиальная разница между ними заключается в том, что «простой» запрос можно сформировать и отправить на сервер и без XMLHttpRequest, например при помощи HTML-формы.

То есть, злой хакер на странице http://evilhacker.com и до появления CORS мог отправить произвольный GET-запрос куда угодно. Например, если создать и добавить в документ элемент

Комментарии

  • Если вам кажется, что в статье что-то не так — вместо комментария напишите на GitHub.
  • Для одной строки кода используйте тег , для нескольких строк кода — тег

, если больше 10 строк — ссылку на песочницу (plnkr, JSBin, codepen…)

  • Если что-то непонятно в статье — пишите, что именно и с какого места.
  • Ссылка на основную публикацию
    Adblock
    detector