Опенсорсные решения для централизованного управления доступом к ресурсам. Зачем нужен Identity Manager и что это такое
№ 4 (180) ’2012
Годы внедрения стандарта PCI DSS в России уже принесла свои плоды в виде наличия сертифицированных инфраструктур компаний — участников платежного процесса. Однако, как и любая другая предметная область, за прошедшие годы тематика PCI DSS обросла большим количеством нетривиальных вопросов. Представляю Вашему вниманию первую статью цикла, посвященную обзору индустрии платежных карт и системе сертификации PCI DSS. Для профессионалов отрасли некоторые моменты покажутся очевидными, однако моей целью является представление читателю целостного описания.
Индустрия платежных карт
Для приведения к общему знаменателю терминологии и основных понятий, о которых пойдет речь в цикле статей, посвященном управлению соответствием требованиям стандарта PCI DSS, предлагаю краткий обзор платежной индустрии. Большая часть информации в этом обзоре, без сомнения, является очевидной для многих читателей. Известно, что международные платежные системы Visa и MasterCard представляют собой сообщества банков-эмитентов, выпускающих платежные карты, и банков-эквайеров, принимающих платежные транзакции по этим картам. Банки имеют различные уровни участия в платежных системах и делятся на принципалов и аффилированных членов. Платежные транзакции из магазинов и других торговых точек могут идти к банкам-эквайерам напрямую, либо через платежные шлюзы. Все участники индустрии платежных карт с точки зрения международных платежных систем делятся на две категории — торгово-сервисные предприятия, они же мерчанты (от англ. merchant — торговец), и поставщики услуг. Мерчанты — это все компании, которые принимают платежные карты в оплату за свои товары или услуги. Примерами таких компаний являются розничные и Интернет-магазины, рестораны, парикмахерские, автозаправочные станции и т. д. Поставщики услуг — это компании, которые предоставляют сервис, чаще всего в сфере информационных технологий, способствующий выполнению платежных транзакций. Это банки, платежные шлюзы, дата-центры, поставщики услуг эмиссии карт, и прочие организации, обслуживающие платежный процесс. Структура индустрии наглядно представлена на рисунке 1.
Следует помнить о том, что международные платежные системы возлагают всю ответственность за обеспечение безопасности данных в индустрии платежных карт на банки-эквайеры. Они ответственны за безопасность карточных данных, поступающих к ним от нижестоящих организаций — мерчантов и поставщиков услуг. То есть за утечку перечня номеров карт в информационной инфраструктуре магазина ответственность перед международными платежными системами понесет банк-эквайер. Существуют механизмы переноса ответственности в индустрии платежных карт, например применение технологии 3-D Secure, однако здесь следует различать ответственность за мошеннические транзакции и ответственность за утечку карточных данных.
Рис. 1. Торгово-сервисные предприятия и поставщики услуг
Стандарты PCI DSS и PCI PA-DSS
Объединив однажды усилия в борьбе с нарушениями безопасности платежных транзакций, международные платежные системы создали в 2006 году общий международный регулирующий орган в сфере безопасности платежных карт — Совет PCI SSC. На эту организацию возложены задачи развития стандартов PCI DSS, PCI PA-DSS и PCI PTS, а также обучения, сертификации и контроля качества работы аудиторов безопасности — QSA-аудиторов.
Все годы существования стандартов ведется дискуссия на тему того, является ли стандартизация правил обеспечения информационной безопасности по принципу контрольной карты, то есть перечня конкретных мер, оптимальным способом защиты карточных данных, или же это излишня формальность. Ведь существует положительно зарекомендовавший себя риск-ориентированный подход, при котором нет предустановленного заранее перечня мер, а есть правило регулярного выполнения оценки актуальных угроз и выявления уязвимостей защищаемой системы. Решение этой дилеммы состоит в том, что стандартизация перечня конкретных мер по примеру PCI DSS полезна на том уровне зрелости системы обеспечения информационной безопасности, когда риск-ориентированная система менеджмента еще не выполнила достаточное количество итераций цикла «анализ рисков — внедрение контрмер — оценка — корректировка», чтобы сформировать эффективную защиту. Примером может служить то, как мама учит малыша не трогать горячую поверхность утюга. Пока утюг еще недостаточно изучен ребенком, или не получен болезненный опыт прикосновения, единственным способом попробовать избежать ожога могут быть только слова взрослой мамы, гласящие: «не трогай утюг, будет больно!».
Стандарт PCI DSS применим к организациям, обрабатывающим, хранящим и передающим данные о держателях карт. Забегая вперед, необходимо уточнить, что Интернет магазины, не обрабатывающие номера карт на своем сайте, а пересылающие клиента на сайт аутсорсного платежного шлюза для выполнения оплаты, тоже попадают под сертификацию по PCI DSS. Однако с точки зрения способа подтверждения соответствия, к ним применим наиболее простой опросный лист (SAQ) типа «А», содержащий в себе всего тринадцать проверочных процедур из двухсот восьмидесяти восьми имеющихся в стандарте PCI DSS версии 2.0.
Объектом применения родственного стандарта PA-DSS, в отличие от PCI DSS, является конкретное платежное приложение, разрабатываемое для продажи неограниченному кругу конечных пользователей — участников индустрии платежных карт. Примерами таких приложений являются программные модули POS-теминалов, авторизационные приложения, а также иные коробочные решения для обработки карточных транзакций. С июля 2012 года согласно требованиям международных платежных систем Visa и MasterCard мерчанты обязаны использовать только сертифицированные по стандарту PA-DSS платежные приложения. Контроль над выполнением этого требования возложен на банки-эквайеры. Существует перечень из тринадцати вопросов, которые позволяет более точно сказать, попадает приложение под программу сертификации по PA-DSS или нет. Этот документ доступен на официальном сайте Совета PCI SSC.
Внедрение PCI DSS
Классический проект по внедрению стандарта PCI DSS в организации обычно состоит из следующих этапов:
- Анализ исходного уровня соответствия
- Приведение к требуемому уровню соответствия
- Подтверждение соответствия
- Поддержка соответствия
Любой из этих этапов может быть выполнен как самостоятельно организацией, так и привлеченным консультантом. Единственное действие, которое не может быть выполнено самостоятельно — внешний сертификационный аудит, если таковой требуется для организации.
Оптимальным и наиболее часто применяемым на практике вариантом является такой, когда часть работ выполняется самой организацией, а часть отдается на аутсорсинг внешнему консультанту.
Схема такого проекта приведена на рисунке 2. Работы по исходной оценке соответствия и разработке рекомендаций по выполнению требований стандарта осуществляются привлеченным консультантом, а непосредственное внедрение изменений в информационные системы осуществляется системными администраторами организации-заказчика. При этом консультант оказывает поддержку и подготавливает сопроводительную документацию, необходимую для сертификации. Затем следуют итоговые проверки защищенности информационной инфраструктуры и процедура подтверждения соответствия стандарту.
Рис. 2. Типовой проект по внедрению PCI DSS
Отдельно следует сказать про варианты подтверждения соответствия стандарту PCI DSS. Для участников индустрии платежных карт существуют три способа подтвердить соответствие — это внешний аудит, внутренний аудит, и заполнение листа самооценки. Внешний аудит выполняется сотрудником внешней аудиторской организацией (Qualified Security Assessor, QSA), сертифицированной Советом PCI SSC. Внутренний аудит проводится прошедшим обучение и сертифицированным по программе Совета PCI SSC аудитором (Internal Security Assessor, ISA). Третий вариант подтверждения выполняется самостоятельно сотрудниками организации путем заполнения листа самооценки (Self-Assessment Questionnaire, SAQ). Правила, регулирующие, каким именно способом подтверждается соответствие стандарту, определяются международными платежными системами индивидуально для разных видов мерчантов и поставщиков услуг, но могут быть переопределены банками-эквайерами. Актуальная версия правил в общем виде всегда доступна на официальных сайтах международных платежных систем.
Следует отметить, что форма листа самооценки SAQ бывает нескольких типов (A, B, C, C-VT, D), а выбор типа листа зависит от специфики обработки карточных данных в организации. Схема применимости различных вариантов подтверждения соответствия приведена в таблице.
В следующей статье цикла «Управление соответствием PCI DSS» я расскажу про определение области применимости PCI DSS в информационной инфраструктуре организации, методы ее уменьшения с целью снижения расходов на внедрение стандарта, а также отвечу на вопрос, подлежит ли сертификационному аудиту процесс эмиссии платежных карт.
Таблица. Варианты подтверждения соответствия PCI DSS
| Вариант | Применимость | Количество проверочных процедур |
| SAQ A | Мерчанты, выполняющие card-not-present транзакции, отдавшие все функции по электронной обработке, хранению и передаче карточных данных поставщику услуг, подтвердившему соответствие PCI DSS. | 13 |
| SAQ B | Мерчанты, использующие POS-терминалы, использующие телефонную линию, не передающие карточные данные через Интернет, и не имеющие электронных хранилищ карточных данных. | 29 |
| SAQ C | Мерчанты, использующие POS-терминалы или платежные приложения, передающие карточные данные через Интернет, и не имеющие электронных хранилищ карточных данных. | 40 |
| SAQ C-VT | Мерчанты, использующие через Интернет виртуальные веб-терминалы от поставщика услуг, подтвердившего соответствие PCI DSS, и не имеющие электронных хранилищ карточных данных. | 51 |
| SAQ D | Все мерчанты и все поставщики услуг, кроме тех, кому согласно требованиям МПС или эквайера необходим ISA- или QSA-аудит. | 288 |
| ISA-аудит | Все мерчанты, кроме тех, кому согласно требованиям МПС или эквайера необходим QSA-аудит. | 288 |
| QSA-аудит | Все мерчанты и все поставщики услуг. | 288 |
Любое объективное и полноценное тестирование на проникновение должно
выполняться с учетом рекомендаций и правил. Хотя бы для того, чтобы быть
грамотным спецом и ничего не упустить. Поэтому, если ты хочешь связать свою
профессиональную деятельность с пентестом – обязательно ознакомься со
стандартами. А в первую очередь – с моей статьей.
Правила и рамки информационного пентестинга представлены в методологиях
OSSTMM
и OWASP
. Впоследствии полученные данные можно легко
адаптировать для проведения оценки соответствия с какими-либо промышленными
стандартами и "лучшими мировыми практиками", такими как, Cobit
,
стандартами серии ISO
/IEC 2700x
, рекомендациями CIS
/SANS
/NIST
/etc
и – в нашем случае – стандартом PCI DSS
.
Безусловно, накопленных данных, полученных в процессе тестирования на
проникновение, для проведения полноценной оценки по промышленным стандартам
будет недостаточно. Но на то он и пентест, а не аудит. Кроме того, для
осуществления такой оценки в полном объеме одних лишь технологических данных по
любому будет мало. Для полноценной оценки требуется интервьюирование сотрудников
различных подразделений оцениваемой компании, анализ распорядительной
документации, различных процессов ИТ/ИБ и много еще чего.
Что касается тестирования на проникновение в соответствии с требованиями
стандарта по защите информации в индустрии платежных карт, – он не намного
отличается от обычного тестирования, проводимого с использованием методик
OSSTMM
и OWASP
. Более того, стандартом PCI DSS
рекомендуется
придерживаться правил OWASP
при проведении как пентеста (AsV), так и
аудита (QSA).
Основные отличия тестирования по PCI DSS
от тестирования на
проникновение в широком смысле этого слова заключаются в следующем:
- Стандартом не регламентируется (а значит и не требуется) проведение атак с
использованием социальной инженерии. - Все проводимые проверки должны максимально минимизировать угрозу "Отказа в
обслуживании" (DoS). Следовательно, проводимое тестирование должно
осуществляться методом "серого ящика" с обязательным предупреждением
администраторов соответствующих систем. - Основная цель такого тестирования – это попытка осуществления
несанкционированного доступа к данным платежных карт (PAN, Cardholder Name и
т.п.).
Под методом "серого ящика" (gray box) подразумевается выполнение различного
рода проверок с предварительным получением дополнительной информации об
исследуемой системе на разных этапах тестирования. Это позволяет снизить риск
отказа в обслуживании при проведении подобных работ в отношении информационных
ресурсов, функционирующих в режиме 24/7.
В общем случае тестирование на проникновение по требованиям PCI должно
удовлетворять следующим критериям:
- п.11.1(b) – Анализ защищенности беспроводных сетей
- п.11.2 – Сканирование информационной сети на наличие уязвимостей (AsV)
- п.11.3.1 – Проведение проверок на сетевом уровне (Network-layer
penetration tests) - п.11.3.2 – Проведение проверок на уровне приложений (Application-layer
penetration tests)
На этом теория заканчивается, и мы переходим к практике.
Определение границ проводимого исследования
В первую очередь необходимо понять границы тестирования на проникновение,
определиться и согласовать последовательность выполняемых действий. В лучшем
случае со стороны подразделения ИБ может быть получена карта сети, на которой
схематично показано, каким образом процессинговый центр взаимодействует с общей
инфраструктурой. В худшем – придется общаться с системным администратором,
который в курсе собственных косяков и получение исчерпывающих данных об
информационной системе будет затруднено его нежеланием делиться своими
уникальными (или не очень, – прим. Forb) знаниями. Так или иначе, для проведения
пентеста по PCI DSS, как минимум, требуется получить следующую информацию:
- сегментация сети (пользовательская, технологическая, ДМЗ, процессинг и
т.д.); - межсетевое экранирование на границах подсетей (ACL/МСЭ);
- используемые Web-приложения и СУБД (как тестовые, так и продуктивные);
- используемые беспроводные сети;
- какие-либо детали обеспечения безопасности, которые необходимо учесть в
ходе проведения обследования (например, блокировка учетных записей при N
попытках неправильной аутентификации), особенности инфраструктуры и общие
пожелания при проведении тестирования.
Обладая всей необходимой информацией, перечисленной выше, можно
организовывать свое временное пристанище в наиболее оптимальном сегменте сети и
приступать к обследованию информационной системы.
Network-layer penetration tests
Для начала стоит провести анализ пробегающего мимо сетевого трафика с помощью
любого сетевого анализатора в "неразборчивом" режиме работы сетевой карты
(promiscuous mode). В качестве сетевого анализатора для подобных целей
замечательно подходит или CommView. Чтобы выполнить этот этап, хватит 1-2 часов работы
снифера. По прошествии этого времени накопится достаточно данных для проведения
анализа перехваченного трафика. И в первую очередь при его анализе следует
обратить внимание на следующие протоколы:
- протоколы коммутации (STP, DTP и т.п.);
- протоколы маршрутизации (RIP, EIGRP и т.д.);
- протоколы динамической конфигурации узла (DHCP, BOOTP);
- открытые протоколы (telnet, rlogin и т.п.).
Что касается открытых протоколов, – вероятность того, что они попадутся во
время снифания проходящего мимо трафика в коммутируемой сети, достаточно мала.
Однако, если такого трафика много, то в обследуемой сети явно наблюдаются
проблемы в настройках сетевого оборудования.
Во всех остальных случаях присутствует возможность проведения красивых атак:
- классической атаки MITM (Man in the middle) в случае, когда используется
DHCP, RIP - получение роли корневого узла STP (Root Bridge), что позволяет
перехватывать трафик соседних сегментов - перевод порта в магистральный режим с помощью DTP (enable trunking);
позволяет перехватывать весь трафик своего сегмента - и др.
Для реализации атак на протоколы коммутации доступен замечательный инструмент
Yersinia. Предположим, что в процессе анализа трафика были выявлены пролетающие
мимо DTP-пакеты (смотри скриншот). Тогда отправка пакета DTP ACCESS/DESIRABLE
может позволить перевести порт коммутатора в магистральный режим. Дальнейшее
развитие этой атаки позволяет прослушивать свой сегмент.
После тестирования канального уровня стоит переключить внимание на третий
уровень OSI. Дошла очередь и до проведения атаки ARP-poisoning. Тут все просто.
Выбираем инструмент, например,
и обговариваем с сотрудниками ИБ детали проведения этой атаки (в том числе,
необходимость в проведении атаки, направленной на перехват одностороннего SSL).
Все дело в том, что в случае успешной реализации атаки ARP-poisoning в отношении
всего своего сегмента может наступить ситуация, когда компьютер атакующего не
справится с потоком поступающих данных и, в конечном счете, это может стать
причиной отказа в обслуживании целого сегмента сети. Поэтому наиболее правильным
будет выбрать единичные цели, например, рабочие места администраторов и/или
разработчиков, какие-либо определенные сервера (возможно контроллер домена,
СУБД, терминальный сервер, etc).
Успешно проведенная атака ARP-poisoning позволяет получить в открытом виде
пароли к различным информационным ресурсам – СУБД, каталогу домена (при
понижении проверки подлинности NTLM), SNMP-community string и пр. В менее
удачном случае могут быть получены хеш-значения от паролей к различным системам,
которые нужно будет за время проведения пентеста постараться восстановить по
радужным таблицам (rainbow tables), по словарю или атакой "в лоб". Перехваченные
пароли могут использоваться где-то еще, и впоследствии это также необходимо
подтвердить или опровергнуть.
Кроме того, стоит проанализировать весь перехваченный трафик на присутствие
CAV2/CVC2/CVV2/CID/PIN, передаваемых в открытом виде. Для этого можно пропустить
сохраненный cap-файл через NetResident и/или
.
Второй, кстати, замечательно подходит для анализа накопленного трафика в целом.
Application-layer penetration tests
Переходим на четвертый уровень OSI. Тут, в первую очередь, все сводится к
инструментальному сканированию обследуемой сети. Чем его проводить? Выбор не так
уж и велик. Первоначальное сканирование можно выполнить с использованием Nmap в
режиме "Fast scan" (ключи -F -T Aggressive|Insane), а на следующих этапах
тестирования проводить сканирование по определенным портам (ключ -p), например,
в случаях обнаружения наиболее вероятных векторов проникновения, связанных с
уязвимостями в определенных сетевых сервисах. Параллельно стоит запустить сканер
безопасности – Nessus или XSpider (у последнего результаты помясистей будут) в
режиме выполнения только безопасных проверок. При проведении сканирования на
уязвимости необходимо также обращать внимание на присутствие устаревших систем
(например, Windows NT 4.0), потому как стандартом PCI запрещается их
использование при обработке данных держателей карт.
Не стоит, при обнаружении критической уязвимости в каком-либо сервисе, сразу
же бросаться на ее эксплуатацию. Правильный подход при тестировании по PCI –
это, во-первых, получить более полную картину состояния защищенности обследуемой
системы (является ли эта уязвимость случайной или она встречается повсеместно),
а во-вторых, согласовать свои действия по эксплуатации выявленных уязвимостей в
определенных системах.
Итогами инструментального обследования должны стать общая картина
реализованных процессов ИБ и поверхностное понимание состояния защищенности
инфраструктуры. Во время отработки сканов можно попросить ознакомиться с
используемой политикой ИБ в Компании. Для общего саморазвития:).
Следующий этап – выбор целей для проникновения. На этом этапе следует
провести анализ всей собранной информации, полученной в ходе прослушивания
трафика и сканирования на уязвимости. Вероятно, к этому моменту уже будут
прослеживаться уязвимые или потенциально уязвимые системы. Следовательно, пришло
время воспользоваться этими недостатками.
Как показывает практика, работа проходит по следующим трем направлениям.
1. Эксплуатация уязвимостей в сетевых сервисах
В далеком прошлом осталось время, когда эксплоитинг был уделом избранных,
способных хотя бы собрать чужой код и (о Боже!) подготовить свой шелл-код.
Сейчас эксплуатация уязвимостей в сетевых сервисах, таких как переполнение
буфера и иже с ними, доступна каждому. Причем, процесс все больше напоминает
игру в жанре "квест". Взять хотя бы Core Impact, в котором весь пентест сводится
к клацанью мышкой по различным выпадающим менюшкам в красивой GUI-обертке.
Подобный инструментарий здорово экономит время, которого при внутреннем пентесте
не так уж и много. Потому шутки шутками, а фичисет, реализованный в Core Impact,
позволяет, особо не утруждаясь, последовательно выполнить эксплуатацию, поднятие
привилегий, сбор информации и удаление следов своего пребывания в системе. В
связи с чем Core Impact пользуется особой популярностью у западных аудиторов и
пентестеров.
Из общедоступных инструментов подобного рода можно упомянуть следующие
сборки: Core Impact, CANVAS, SAINTexploit и всеми любимый Metasploit Framework.
Что касается первой тройки, – это все коммерческие продукты. Правда, некоторые
старые версии коммерческих сборок утекали в свое время в интернет. При желании
можно отыскать их в глобальной сети (естественно, исключительно с целью
самообразования). Ну а весь бесплатный свежачок сплоитов доступен и в Metasploit
Framework. Конечно, существуют zero-day сборки, но это уже совсем другие деньги.
Кроме того, бытует спорное мнение, что при проведении пентеста их использование
является не совсем честным.
На основе данных сетевого сканирования можно немного поиграть в хакеров:).
Предварительно согласовав список мишеней, провести эксплуатацию обнаруженных
уязвимостей, а после выполнить поверхностный локальный аудит захваченных систем.
Собранная на уязвимых системах информация может позволить повысить свои
привилегии и на других ресурсах сети. То есть, если в процессе проведения атаки
ты порутал винду, то не лишним будет снять с нее базу SAM (fgdump) для
последующего восстановления паролей, а также секреты LSA (Cain&Abel), в которых
зачастую может храниться в открытом виде много полезной информации. К слову,
после проведения всех работ собранная информация о паролях может расцениваться в
контексте соответствия или несоответствия требованиям стандарта PCI DSS (п. 2.1,
п.2.1.1, п.6.3.5, п.6.3.6, п.8.4, п.8.5.x).
2. Анализ разграничения доступа
Анализ разграничения доступа необходимо выполнять на всех информационных
ресурсах, на которые удалось реализовать НСД. И на общих файловых ресурсах
Windows (SMB), на которых открыт анонимный доступ – тоже. Зачастую это позволяет
получить дополнительную информацию о ресурсах, которые не были обнаружены во
время сетевого сканирования, или наткнуться на другую информацию, различной
степени конфиденциальности, хранимую в открытом виде. Как я уже говорил, при
проведении тестирования по PCI, в первую очередь, поиск направлен на обнаружение
данных держателя карт. Поэтому важно понимать, как могут выглядеть эти данные и
искать их во всех информационных ресурсах, к которым имеется соответствующий
доступ.
3. Атака типа брутфорс
Необходимо, как минимум, проверить дефолты и простые комбинации логин-пароль.
Подобные проверки требуется провести, прежде всего, в отношении сетевого
оборудования (в том числе, для SNMP) и интерфейсов удаленного администрирования.
При проведении AsV-сканирования по PCI DSS не разрешается осуществлять "тяжелый"
брутфорс, который может привести к состоянию DoS. Но в нашем случае речь идет
про внутренний пентест по PCI, а потому в разумном виде и без фанатизма стоит
осуществить атаку по подбору простых комбинаций паролей к различным
информационным ресурсам (СУБД, WEB, ОС и т.п.).
Очередной этап – это анализ защищенности Web-приложений. При пентесте по PCI
про глубокий анализ Web речи не идет. Оставим это QSA-аудиторам. Здесь
достаточно осуществить blackbox-сканирование с выборочной верификацией
эксплуатабельных server/client-side уязвимостей. В дополнение к уже упомянутым
сканерам безопасности можно воспользоваться сканерами, заточенными под анализ
Web. Идеальное решение – это, безусловно, HP WebInspect или
(который, кстати, на "отлично" детектит баги в AJAX). Но все это –
дорогая и непозволительная роскошь, а раз так, то нам подойдет и w3af, который в
последнее время набирает обороты в плане детектирования различного рода
уязвимостей в Web-приложениях.
По поводу ручной верификации уязвимостей в Web! Необходимо, как минимум,
проверить механизмы аутентификации и авторизации, использование простых
комбинаций логин-пароль, дефолтов, а также всеми любимые SQL–инъекции,
инклудинг-файлов и выполнение команд на сервере. Что касается client-side
уязвимостей, то, кроме верифицирования возможности эксплуатации уязвимости, тут
более ничего не требуется. А вот с server-side необходимо немного повозиться,
ибо все-таки пентест, хоть и по PCI DSS. Как я отмечал ранее, мы ищем PAN,
Cardholder Name и CVC2/CVV2 опционально. Вероятнее всего, подобные данные
содержатся в СУБД, а потому в случае нахождения SQL-инъекции стоит оценить имена
таблиц, колонок; желательно сделать несколько тестовых выборок, чтобы
подтвердить или опровергнуть присутствие подобных данных в базе в
незашифрованном виде. Если столкнулся с Blind SQL-иъекцией, то лучше натравить
на Web-сервер (с
ключом --dump-all), который на текущий момент работает с MySQL, Oracle,
PostgreSQL и Microsoft SQL Server. Этих данных будет достаточно для демонстрации
использования уязвимости.
Дальнейший этап – это анализ защищенности СУБД. Опять же, есть отличный
инструмент – AppDetective от "Application Security Inc.", но это дорогое
удовольствие. К сожалению, аналогичного сканера безопасности, который бы выдавал
такой объем информации, как это умеет AppDetective, и поддерживал столько же
СУБД, в настоящее время не существует. И потому приходится брать на вооружение
множество отдельных, несвязанных между собой продуктов, которые заточены под
работу с определенными вендорами. Так, для ораклятины минимальный набор
пентестера будет следующим:
- Oracle Database Client – окружение для работы с СУБД
- Toad for Oracle – клиент для работы с PL/SQL
- Oracle Assessment Kit – брут пользователей и SID’ов баз
- различные сценарии на языке PL/SQL (например, аудит конфигурации или
возможность спуститься на уровень выполнения команд ОС)
Заключительный этап тестирования на проникновения по PCI – это анализ
защищенности беспроводных сетей, вернее, даже не анализ, а поиск точек доступа,
использующих уязвимые конфигурации, таких как Open AP, WEP и WPA/PSK. С другой
стороны, стандарт PCI не запрещает проводить более глубокий анализ, в том числе
с восстановлением ключей для подключения к беспроводной сети. Потому имеет смысл
осуществить подобного рода работы. Основным же инструментом на этом этапе,
конечно, будет aircrack-ng. Дополнительно можно провести атаку, направленную на
беспроводных клиентов, известную как "Caffe Latte", с использованием все того же
инструмента. При проведении обследования беспроводных сетей можно смело
руководствоваться данными с сайта
Wirelessdefence.org .
Вместо заключения
По результатам тестирования проводится анализ всей собранной информации в
контексте соответствия техническим требованиям стандарта PCI DSS. И как я уже
отмечал в самом начале, таким же образом данные, полученные при пентесте, можно
интерпретировать в контексте любого другого высокоуровневого документа,
содержащего технические критерии и рекомендации к системе управления
информационной безопасности. Относительно используемого шаблона для отчетных
документов по PCI, – можно использовать требования MasterCard к отчету по
AsV-сканированию. В них предусматривается разделение отчета на два документа –
документ верхнего уровня для руководителя, в котором содержатся красивые графики
и указан процент соответствия текущего состояния системы с требованиями PCI DSS,
и технический документ, содержащий протокол проведенного тестирования на
проникновение, выявленные и эксплуатируемые уязвимости, а также рекомендации по
приведению информационной системы в соответствие с требованиями MasterCard.
Засим могу попрощаться и пожелать удачи в исследованиях!
WWW
pcisecuritystandards.org - PCI Security Standards Council.
pcisecurity.ru – портал,
посвященный PCI DSS от Информзащиты.
pcidss.ru – портал, посвященный
PCI DSS от Digital Security.
isecom.org/osstmm - Open
Source Security Testing Methodology Manual.
owasp.org - Open Web Application
Security Project.
Многие полагают, что на сегодняшний день полноценного интегрированного аналога MS Active Directory, а также Group Policy (Групповых политик) в мире GNU/Linux пока еще не существует. Тем не менее, разработчики со всего мира предпринимают попытки воплотить в жизнь подобные технологии в рамках UNIX-систем. Одним из ярких примеров можно назвать eDirectory от Novell об особенностях которой мы поговорим далее.
Интересно, что поддержка Групповых политик была реализована в Samba 4, после появления которой стали разрабатываться эффективные средства по настройке политик групп. Однако прежде большинству системных администраторов приходилось ограничиваться logon-скриптами или же политиками системы NT4.
Чего же позволяет добиваться Samba4? Многие сегодня наловчились использовать данное решение в качестве AD, то есть контроллера домена в связке с файловыми серверами, базирующимися на этом же решении. В итоге Пользователь получает минимум пару настроенных серверов с Samba4, один из которых выполняет функцию контроллера домена, а второй выступает в качестве Member Server с пользовательскими файлами.
Сегодня проблемы, связанные с техобслуживанием и регистрацией пользователей сети в рамках одноранговых сетей, ответственно берутся решить сразу несколько ведущих компаний-производителей современного ПО. Фаворитами среди таких разработчиков сегодня считаются Microsoft с ее ранее упомянутой Active Directory и Novell со своим eDirectory, также упомянутый вначале данной статьи.
Решение вышеобозначенных проблем в данном случае заключено в создании каталогизирующих служб или БД, которая позволяет сохранять информацию в фиксированном хранилище обо всех учетных пользовательских записях, а также , что позволяет существенно облегчить контроль сетей.
Рассмотри обозначенные выше и другие технологии организации работы с пользовательскими сетями в разрезе их преимуществ и особенностей.
Active Directory – технологические особенности
По сути, AD представляет собой упорядоченное вместилище данных, предоставляющее достаточно удобный способ доступа к сведениям о всевозможных сетевых объектах. Это также оказывает существенную помощь приложениям и пользователям находить данные объекты.
Для определения расположения в AD используется распределенное именное пространство или DNS (Domain Name System). Для работы с базой данных в AD имеется набор специального ПО, а также инструменты, предназначенные для прикладного программирования.
Даже при неоднородной структуре систем в сети AD позволяет провести единую регистрацию за счет упрощенного протокола, относящегося к LDAP-службе каталогов.
Данная система хороша тем, что она масштабируется и легко расширяется. Active Directory сохраняет собственную схему или набор образцов классов объекта и его атрибутов непосредственным образом в каталоге. Таким образом, схема подразумевает возможность производить изменения схемы в динамическом режиме.
Важная особенность AD заключается в ее отказоустойчивости, а также наличии распределенной БД. Служба каталогов способна охватить сразу несколько или же один домен.
Примечательной является и функция делегирования, то есть предоставление прав администрирования от администратора для отдельных групп и пользователей на деревья и контейнеры, а также возможность наследования.
Служба каталогов AD позволяет достаточно просто и оперативно развертывать достаточно качественные и надежные сети, которые могут выстраиваться в соответствии с самыми разными индивидуальными требованиями.
Технологии с использованием eDirectory
Еще до появления MS Active Directory активно использовались иные способы управления БД.
Так следует отметить службу «Bindery» («Подшивка») от Novell, которая представляет собой однородную БД. В рамках такой базы данных одни записи не имеют явной взаимосвязанности с другими записями. Такая БД в первую очередь ориентирована на работу с сервером. Это означает, что каждый сервер в данном случае будет обеспечен уникальной подшивкой, содержащей в себе права доступа и настройки сетевых объектов. Данный вариант управления БД предполагает, что ресурсы сети расцениваются как объекты, имеющие непосредственную связь с корневым серверным каталогом.
Формирование подшивки базируется на следующих компонентах:
Свойств – характерных черт для каждого объекта в рамках подшивки (адреса межсетевого типа, ограничительные факторы и пароли);
Объектов – физических и логических составляющих сети, которым могут быть присвоены имена (файл-серверы, пользовательские группы, пользователи).
Свойства наборов инфоданных – это формы инфоданных, которые хранятся в рамках подшивки (числа, таблицы, текст, время, дата, адрес сети и т. п.)
Когда на светпоявился NetWare4xx, компания Novell представила миру и новую службу каталогов eDirectory, которая изначально называлась NDS в данной версии NW. С версии 6.x она стала именоваться не иначе, как eDirectory.
В рамках данной службы, равно как и в Active Directory, была реализована база данных, выстраивающаяся по иерархическому принципу. Это дает возможность взаимодействия одних объектов сети с другими.
Возможность отказа от необходимости в подчинении иерархическому порядку является одним из существенных преимуществ данного решения. На некоторых участка дерева могут быть задействованы подшивки, что, естественно, многие находят весьма удобным решением.
Также стоит отметить, что eDirectory-сервер может функционировать и на платформах которые отличаются от NetWare.
Во многом возможности данного решения совпадают с аналогичными возможностями, представленными в MS Active Directiry. Так, например, посредством eDirectory можно производить репликацию в автоматическом режиме, а также наследование и делегирование.
Главной сложностью в процессе сетевой настройки, при установленной в сети eDirectory является подбор специалистов, которые должны иметь соответствующие навыки работы с этим решением.
Филипп Торчинский: Добрый день! Сегодня я почти не буду говорить про Open Solaris, хотя обычно я как раз об этом рассказываю.
Сегодня мы поговорим о том, как и зачем можно использовать те или иные альтернативы службы каталогов Active Directory в UNIX. Строго говоря, это будут не совсем альтернативы AD. Но я еще раз озвучу свое мнение о том, как будет развиваться ситуация в дальнейшем, в каком направлении. Немного расскажу о том, как настраивать те решения, которые будут популярны в будущем, - опять же, по моему мнению. В докладе предусмотрен отдельный кусок об Identity Manager.
Как правило, я рассказываю о вещах, которые я своими руками настраивал и о которых могу все рассказать. Сегодня будет немного по-другому. Я буду рассказывать о концепции и упомяну то, что сам настраивал. Я довольно много пользовался этим сервисом. Могу рассказать, как он выглядит с точки зрения пользователя, и что в этом может быть хорошего или плохого.
Одна из главных задач любого проектировщика любой системы - избежать ситуации, когда мы с помощью какого-нибудь очень мощного инструмента делаем какую-нибудь довольно простую работу. Хотя именно так часто и происходит в жизни.
Наверняка многие из вас наблюдали набор примитивных текстов, например, в Microsoft Word или в OpenOffice Writer. В принципе, эти тексты достойны того, чтобы их набирали в текстовом терминале, в Notepad или в любом его аналоге. Но этим текстам так повезло, что их набирают в очень мощных редакторах.
Я, на самом деле, часто думаю об этом. Поскольку здесь собрались люди, от которых что-то зависит в этом мире, я надеюсь, что общими усилиями мы сможем привести ситуацию к состоянию, когда наши клиенты, наши сотрудники, и все, кто связан с нами, будут тратить меньше времени и ресурсов на выполнение простых действий сложными средствами.
Теперь я хотел бы снять шляпу перед разработчиками корпорации Microsoft. Мы с коллегами пришли к общему мнению, что в целом Active Directory — это хорошо. Хорошо, что это решение существует, им действительно можно пользоваться. Другое дело, что службу каталогов Active Directory часто используют там, где без нее было бы ничуть не хуже.
Что хорошего в Active Directory? Для чего его можно использовать?
Прежде всего, Active Directory подходит для управления пользователями (группами, ролями пользователей и так далее). Строго говоря, решение Active Directory непосредственно с этим связано, но не является средством обеспечения этого. Служба каталогов Active Directory позволяет выходить в сеть с разных компьютеров, обеспечивает функциональность перемещаемых профилей (англ. roaming profiles).
Эти профили стали моей головной болью на 2 года. Я был главой IT-отдела компании, где во всех офисах по всей стране использовались эти самые перемещаемые профили. Они могли иметь размер в 2 или 3 гигабайта и чудеснейшим образом тянуться из питерского офиса в московский офис, потому что сотрудник приехал сюда в командировку и решил поработать.
Это как раз характерный пример неэффективного использования неплохой концепции, при котором она оказывается жутко неудобной.
Кроме этого, Active Directory, естественно, используется для управления доступом, поскольку там написано, кому куда можно. Еще Active Directory довольно широко применяется в тех системах, где сеть гетерогенная. В этом случае мы настраиваем доступ через PAM, аутентификацию, доступ через Active Directory к каким-то ресурсам, которые физически лежат на компьютерах, никак не связанных с Active Directory. Например, у нас есть работающий под Linux сервер, на котором требуется раскладывать какие-то файлы. Естественно, можно использовать Active Directory и для аутентификации через веб.
Еще есть одна вещь, на которой я сегодня не буду останавливаться подробно. Просто яскажу, что это с помощью Active Directory делают. Как подобное реализовать для UNIX-приложений в UNIX-системах, я догадываюсь, но это никак не связано с темой доклада.
Это так называемые групповые политики и, в частности, управление приложениями, при котором мы для различных групп или пользователей можем по-разному настроить "поведение" конкретных приложений.
Эту штуку в той функциональности, о которой я сегодня буду рассказывать, никак не реализовывали, насколько мне известно. Это нужно делать либо другими средствами, либо добавлять к имеющимся средствам что-то еще.
Вообще для чего используются компьютеры (неважно, под UNIX или нет)? Целей много, но для каждой группы задач существует наиболее удобный протокол. У нас есть протокол SSH — он придуман для моих коллег системных администраторов. Понятно, что обычным людям он вряд ли нужен.
Протоколы FTP и HTTP нужны почти всем, кто хоть когда-нибудь что-нибудь заливал на хостинг.
Естественно, всем нужна почта. Когда я, например, ставлю себе какую-то новую систему на компьютер или запускаю LiveCD и не вижу там работающей почты, меня это уже раздражает. Хотя еще лет пять назад я бы этому не удивился. Мобильный телефон, который не умеет читать e-mail, — это просто безобразие какое-то. Хотя от домашнего телефона мы такого не ждем, как правило.
Еще одна функциональность, которая, как правило, требуется в любой компании, где количество людей больше двух. Это возможность использования одинаковой рабочей среды на разных компьютерах. Это требуется везде — начиная от таких хрестоматийных вариантов, как группа операторов, сидящих в банке или в call-центре (последних может быть до человек 400 в ряд), и заканчивая менее распространенными вариантами — такими, как администрация университета, где сотрудники перемещаются из одного корпуса в другой. Всем этим людям нужно иметь одну рабочую среду на любом компьютере.
Про средства обеспечения этой рабочей среды я сейчас и расскажу. Эта часть доклада никак не связана с аналогами Active Directory. Это, скорее, некое решение, которое позволяет воплотить то, что часто делают с помощью Active Directory, но сильно не нагружает систему. Это очень простое решение. Скорее всего, многие из вас им уже пользовались или хотя бы видели его, или даже продавали его, — не знаю.
Есть такая старая штука, как терминал. Они существовали еще до 1969-го года. В 1969-м году, когда придумали UNIX, терминалы уже были. Неудивительно, что с терминалов все довольно хорошо работает. Современным вариантом терминала является то, что, например, в компании Sun называлось Sun Ray. Сейчас это по-прежнему называется Sun Ray, но производится уже в компании Oracle.
Аппаратная часть представляет собой X-Terminal с интернет-портом и USB-портом. Еще там есть аудиовыходы и входы. Можно подключить наушники, слушать любимую музыку, можно включить флешку — все будет работать замечательно. Плюс к этому — оно еще умеет читать смарт-карты, поэтому можно делать аутентификацию по смарт-картам.
Кроме Sun Ray существует еще один продукт (его название я не помню), который входит в семейство Virtual Desktop Infrastructure.
Это такой виртуальный Sun Ray. Когда вы приходите к начальнику и говорите: «Слушайте, такое дело, Петр Петрович, надо бы перевести нашу группу технической поддержки на терминалы, потому что они вместо того, чтобы быстро отвечать на вопросы, играют в „Косынку“ на том, что у них там стоит». Или: «Нам надоело чинить их блоки питания, потому что они каждую неделю выходят из строя, потому что так и не можем починить кондиционер».
Это, естественно, не слишком радует Петра Петровича, потому что нужно менять технику, техника вроде недавно была закуплена... Пять лет должен стоять компьютер, пока его не спишут, иначе нехорошо по бухгалтерии.
Можно вместо техники применить виртуальные Sun Ray. Поставить виртуальные рабочие станции. Решение будет работать на имеющейся системе и "делать вид", что оно как бы терминал.
С терминалами мы закончили. Теперь посмотрим, как устроена и для чего нам может понадобиться система, являющаяся в некотором смысле аналогом Active Directory. Я еще раз подчеркиваю, что она не является строгим функциональным аналогом.
Серверы приложений
Glassfish — это стандартный сервер приложений, который, вообще говоря, похож на Tomcat, но, в отличие от него, он еще умеет играть роль не только веб-контейнера, но и JB-контейнера (который Enterprise Java...). Кстати, то, что раньше назвалось просто Glassfish, теперь называется Oracle Glassfish Server.
Оно, например, может работать в Oracle Solaris. У меня оно работает в Open Solaris.
Этот сервер приложений позволяет разворачивать самые разные веб-приложения, в том числе Liferay. Про него я сегодня говорить особенно не буду. Тем из вас, кто еще не знает, что оно существует, мой совет: обратите внимание. Это классная штука. Я предполагаю, что в довольно скором будущем этого будет значительно больше, чем сейчас.
Думаю, через некоторое время — в течение года-двух — наверняка появятся Java-хостинги в России (за границей они уже есть). Liferay — это довольно удобная платформа, чтобы делать любые веб-сайты. В принципе, веб-сайт на Liferay — простенький, на 5 страниц, с контентом, с картинками, с минимальным оформлением — я сделал примерно за полчаса.
Еще есть реализация этого же портала, который называется WebSpace. Он основан примерно на том же коде, но был сделан внутри Sun. Liferay — это продукт сообщества, который к Sun имеет слабое отношение — компания Sun вкладывала очень немного денег и усилий в его создание.
Это был пример сервера приложений.
Теперь посмотрим, что стоит за сервером приложений. За сервером приложений стоит то, что позволяет нам аутентифицироваться на этом сервере приложений, а также позволяет этому серверу и работающим на нем приложениям определять наши права доступа к разным объектам.
Это Identity Manager, Directory Server и Access Manager. В принципе, компонентов, обеспечивающих аутентификацию и управление доступом к неким веб-ресурсам, может быть и больше, но это самое интересное.
Чтобы людям было удобно, довольно естественно предоставлять централизованный доступ, объединять веб-ресурсы логически (как правило) или организационно, финансово. Нужно, чтобы у людей была возможность заходить на один веб-ресурс и автоматически получать доступ ко всем остальным. Для этого придумали хорошо известную штуку под названием технология единого входа (SSO, Single Sign On). Раз выполнили вход — дальше все работает. Можно больше не входить в систему.
Это похоже на то, к чему мы привыкли, например, в системах Windows Client и Windows Server, когда мы "залогинились" один раз — и дальше по всем файлам "ходим".
Возникает резонный вопрос: часто ли нам нужно "ходить" по файлам? Из практики группы, где я работаю последние 3 года (даже больше), я вижу, что на самом деле "хождение" по файлам и хранение файлов в папках довольно часто не требуется. У меня есть собственный ноутбук, где есть все, что мне необходимо. Все, что наши группы делят между собой, лежит на общем вики.
Существуют разные варианты реализации вики. Это может быть бесплатный движок, который называется TWiki. Есть еще много решений, которые работают в таком же режиме. Функционирует много бесплатных хостингов, где можно, например, размещать какие-то проекты, — там вики предоставляется бесплатно как элемент управления проектом.
Это довольно популярная штука. Поэтому, в частности, когда вы думаете, какую инфраструктуру построить у себя в компании, вариант, когда у вас нет файлового сервера, но есть некий веб-ресурс, куда все закачивают файлы и берут их оттуда тоже (в соответствии с положенными им полномочиями), — это довольно логичная схема. Тем более что все больше и больше поднимается тема переноса ресурсов в веб.
Кстати, у меня была большая просьба к разработчикам 1С-продуктов: надо срочно придумать такую штуковину, которая называется web-based бухгалтерия. Мне ее ужасно не хватает.
Реплика: — Есть. Филипп Торчинский: — Она совсем такая web-based? Я что-то упустил? Давно она есть? Реплика: — Уже появилась. Филипп Торчинский: — Отлично. Спасибо вам большое! Видимо, я пропустил что-то за последние несколько месяцев и не видел. Полгода назад ее, по-моему, еще не было. Уже есть. Отлично. Спасибо вам за хорошую новость!Теперь вернемся к технологии единого входа. Там удобно сделать, чтобы было два варианта обращения клиента к серверу единого входа.
Первый вариант — когда мы обращаемся к некоему веб-ресурсу, например, работающему на том же Glassfish. Это просто Java-приложение, которое обеспечивает единый вход (аутентификацию и дальнейшие действия). Оно обращается к PAM, который из привычных источников аутентификации "вытягивает" информацию.
Хорошо, если есть обратный вариант: мы обращаемся к PAM, а он — к серверу единого входа и умудряется у него что-то спросить.
Второй вариант, к сожалению, пока не реализован — по крайней мере, я не видел реализации. Первый вариант реализован, я даже его попробовал. Я постараюсь объяснить, как его воплотить.
В феврале этого года компания ForgeRock решила, что она сделает "forge" проекта OpenSSO, потому что компания Oracle, как известно, в феврале официально завершила сделку по покупке Sun.
Код OpenSSO проекта, с точки зрения ForgeRock, было бы интересно вытащить из репозитория и дальше с ним что-то сделать (поскольку лицензия позволяет). Отлично. Пока что никаких сведений о том, что Oracle что-нибудь плохое будет делать с OpenSSO, нет. Более того, есть сведения, что с ним все будет в порядке.
Почему я советую скачивать именно OpenAM, который и есть та же самая сборка, только от ForgeRock? Потому что на сайте ForgeRock лучше всего описано, как это устанавливать. Самое хорошее описание, как ставить OpenSSO, я видел там.
Теперь нужно установить Glassfish. В Open Solaris нужно при распаковке установить флажок «поставить Glassfish» — он будет установлен. Можно просто скачать Glassfish и запустить программу установки.
Далее нужно запустить демон/daemon amunixd, и системой уже можно пользоваться. OpenSSO будет работать через PAM. Неизвестно, нужно ли вам это, — может быть, вам нужно что-то еще. Но если вам нужно, чтобы все через PAM работало, то это делается, как я описал.
Я рассказал, как правильно и быстро в OpenSolaris поставить Glassfish. Точнее, как поставить — это понятно. Интереснее — как настроить домен.
Объясню вкратце, что такое домен применительно к Glassfish. У нас есть некий сервер приложений, и мы хотим на нем развернуть какое-то приложение. Это приложение нельзя развертывать в вакууме. Нужно ему создать какую-то оболочку, куда будут записываться все файлы, которые с ним связаны, и какие-то настройки. Внутри этой оболочки будут развертываться еще какие-то дополнительные компоненты приложений и так далее.
Эта штука называется домен. Она к домену в смысле нечто.ru не имеет никакого отношения. К интернет-доменам это не имеет отношения. Это просто название для совокупности объединенных, связанных между собой компонентов. В принципе, у домена будет какое-то доменное имя (с точки зрения интернет-домена), но это уже потом. Вы его настроите при необходимости.
Теперь самый важный момент. При настройке единого входа нужно указать полностью определенное доменное имя.
На самом деле, в инструкции от ForgeRock крупными буквами на желтом фоне написано: «Напишите FQDN в файл /etc/hosts». Если этого не сделать, то будет выдана малопонятная ошибка. Получится странная диагностика. Что не так, будет абсолютно непонятно.
Он скажет, что вы не сможете обратиться к 80-му порту. Почему не можете? Неизвестно. Важный момент. При настройке этой конфигурации обязательно указывайте в файле /etc/hosts полностью определенное имя вашего хоста.
Заходите по адресу, выполняете вход (по умолчанию администратора зовут amadmin), выбираете Authorization->Unix. Можно выбрать другие варианты авторизации, если требуется. Но в Unix все будет работать через PAM, соответственно.
Зачем нужен Identity Manager и что это такое?
Identity Manager от Oracle "умеет" работать с кучей разных источников информации. Причем в одном источнике информации некий объект зовется Иван Петрович, в другом он Ваня, в третьем он Иван. В этих источниках информации что-то еще про него написано.
Что важно? Что в этих источниках информации не обязана содержаться информация типа первичного ключа (англ. primary key). Нет уникального идентификатора, который лежит в каждом из этих источников. Просто с помощью инструментов управления Identity Manager вы можете разными способами связать между собой разные записи из разных источников информации.
Плюс к этому Identity Manager обеспечивает синхронизацию. Если, например, кого-нибудь увольняют с работы, то его учетная запись удаляется из списка сотрудников, еще из какого-то списка — например, должников или кредиторов организации. В общем, из всех имеющихся источников информации запись удаляется.
Соответственно, если происходит модификация, например, меняются какие-то поля, то это тоже синхронизируется между разными источниками информации, если эти поля там есть.
В качестве стратегического проекта у Oracle остался Oracle Identity Manager, который существовал и раньше. Проект, который назывался Sun Identity Manager, тоже остается. Он будет существовать в прежнем режиме, но главным продуктом, который продает Oracle, будет Oracle Identity Managemer.
Identity Manager — это, на самом деле, вещь, которая стоит каких-то осмысленных денег. Я знаю, что разные клиенты Sun и Oracle в России его действительно покупают.
Есть еще сущность, которая называется Directory Server, о которой мы чуть раньше говорили. Это просто один из вариантов источников информации для Identity Manager. Как правило, это обычный LDAP-сервер. Есть конкретный продукт, он называется OpenDS, который компания Oracle обещает поддерживать. Это просто LDAP-сервер, написанный на языке Java.
Использовать его удобно. Если вам не хочется собирать ничего лишнего, вы можете просто взять этот OpenDS и развернуть его на том же Glassfish.
Расскажу про взаимодействие между клиентом, сервером приложений, Access Manager и Identity Manager.
Есть клиент, который спрашивает доступ к файлу, например, у DEP-сервера приложений с веб-интерфейсом под названием веб-контейнер. К файлу определены не те права доступа. Сервер приложений "спрашивает" у программы Access Manager, можно ли дать доступ к этому файлу.
Access Manager обращается к Identity Manager: «Что у нас с идентичностью такого товарища?» Ему возвращается информация о том, что у товарища в системе роль суперадминистратора. Access Manager говорит: «Этому можно». Информация направляется серверу приложений, например, Glassfish: «Да, можно». Файл выдается.
Вероятно, вы знаете, что в nsswitch.conf в тех системах, где он есть, — например, в Debian и в OpenSolaris можно написать слово ldap в том месте, где определяется, откуда брать аутентификационную информацию. Сведения о том, как это настраивать, есть на на opennet, где описано необходимое добавление к схеме LDAP.
Это самое главное — то, как будет выглядеть будущее, если мы не будем слишком сильно нажимать на него, чтобы оно выглядело как-то иначе. Вариант первый — на что, я очень надеюсь, должны перейти все госслужбы, которые сейчас сообщают мне в окошко: «Извините, мы не можем ничего сделать. У нас компьютер завис, а системный администратор придет завтра». В такие места, безусловно, нужно ставить терминалы, чтобы был один сервер, где системный администратор есть всегда.
Кроме этого, очевидно, есть ситуации, при работе с САПР, когда придется составлять сервер и какие-то рабочие станции, и где приложения с какими угодно клиентами (например, с мобильными телефонами) для всего остального.
Спасибо большое вам за информацию, что 1С:Бухгалтерия уже сделала то, чего мне не хватало.
Спасибо вам! У меня, кажется, осталось 30 секунд на ответы на вопросы.