Как долго у вас это работает (возможно проглядел)?
Вопрос хороший. В основе основ везде Debian 11, но сама freeipa развернута может быть только на ОС Centos, в нашем случае использовали Centos 8.
На каких дистрибутивах?
Везде есть свои сложности, меня лично функционал и работоспособность freeipa вполне радует, очень большие сложности были лишь при первичной инсталяции и при создании реплики.
Был опыт с FreeIPA раньше, и опыт был печальный. Может сейчас лучше стало?
Информация обновлялась периодически каждые 60 секунд. О каких требованиях со стороны ИБ по уменьшению лага стоит вопрос? Как эти 2 момента связаны в контексте Информационной Безопасности подскажите пожалуйста?
С какой частотой обновляется информация о изменении членства в группах? Были ли требования от ИБ по уменьшению этого лага? Как они решались?
Про бизнес-пользователей в рамках статьи речи не идёт, статья рассказывает лишь о внедрении возможных способов авторизации в продуктовую или тестовую среду для администраторов. С вопросом использования Keycloak для бизнес-пользователей пока честно говоря познакомиться не получилось, но насколько я знаю эти параметры стараются разделять точно на уровне Realm для того, чтобы как минимум структурно разделить извлекаемых или заведённых пользователей в keycloak.
Что касается времени жизни токенов как для администраторов, так и для бизнес-пользователей, то подразумеваю, что они могут и должны быть разными. А значения, которые необходимо выставить трактует и бизнес, и КБ.
Время жизни токенов у администраторов инфраструктуры и у бизнес-пользователей одинаковое? Инфра и приложения в одном realm'е или в разных?
Проблем с производительностью не было при извлечении как отдельной группы пользователей, так и всей архитектуры, но тут можно и явно отметить ряд условий нашей инфраструктуры. 1. Исходная freeipa имела всего 500 пользователей, но в ней также присутствовала сложная структура вложенности групп. 2. У нас везде имеется широкий запас по ресурсам. 3. Отличная и стабильная ширина канала на сетевом уровне.
Были ли проблемы с производительностью при sync'е пользователей и\или большом количестве авторизаций? С openldap у меня - да, с freeipa не знаю. Пробовали ли вы прикрутить к этому делу kerberos как для решения проблем с производительностью и\или для повышения удобства работы пользователей? В adfs неплохо работает, с freeipa опять же не знаком.
Не проверялся данный момент, так как по стандартам имена пользователей only English.
Были ли проблемы с интернационализованными именами? Т.е. лучше когда в этих труднодоступных местах зубов нет - и все на английском, но если есть - работает? KC да - на счет интеграшки интересно.
По условию ТЗ таких требований отражено не было.
Не было ли возражений по использованию group mapper'а с т.з. "единой точки ответственности" от ИБ? Обычно просят ldap role mapper.
Этот вопрос на данный момент оформлен в виде задачи и он будет ещё решаться. Вопрос георепликации - это очень масштабная вещь и учитывая, что у нас закрытый контур - явно возникают проблемы связанные с сетью. Для поднятия георезерва как минимум нужно произвести долгое согласование с КБ и проработать новую архитектуру, учитывая все риски.
Как обеспечивалась HA решения? Была ли георепликация?
Статья не просто про то как настроить федерацию) Вариантов решения задач авторизации существует очень много, главная проблема возникает, когда ты пытаешься разобрать все возможные вариант, учитывая что это должно быть безопасно, стабильно, удобно и актуально. Когда производилась настройка всех процессов и погружение в аспекты описанные выше, было страшное огорчение, что сама документация Keycloak не соответствует актуальным версиям своего ПО и возникают сложности в настройке всевозможных процессов.
Обычно в процессе решения этих и им подобных вопросов становится больно - а просто "настроить федерацию" проблем как раз не вызывает.
Спасибо, тоже относительно не давно наткнулись на данный эскпортер, тестируем сейчас его работу, но хотелось бы всё же решение из коробки на уровне функционала Cloud Eye.
Привет, никто не говорит, что его нет) Хочется лишь сказать, что он не работает. Правила фаервола присутствуют на нодах, но свой функционал не выполняют.
Он ведь там есть из коробки, нужно лишь при создании кластера выбрать режим tunneling, а не то что предлагает по умолчанию - routing. Выходит что вы создали кластер с routing и сделали свои городушки.
Проводились работы, анализ проблемы и решения кроме описанного ранее, найдено не было.
Относительно вопроса с получением реальных ip адресов не совсем согласен. Использовали в ходе своих работ параметр obtain client ip и никаких дополнительных плагинов не требовалось.
И отдельный момент по балансировщикам - простое требование, получать реальные адреса клиентов через L4 балансировщик вовлекает вас в путешествие установки TOA плагина https://support.huaweicloud.com/intl/en-us/usermanual-elb/en-us_elb_06_0001.html когда в других облаках - это работает "из коробки". Да есть вариант так не делать, переплатив за балансировщик уровня dedicated.
Привет, спасибо за вопрос. Тут скорее требование со стороны заказчика, а не наше желание или выбор. Именно поэтому и решили описать проблемы, с которыми столкнулись и какие варианты решения были найдены.
По стандарту мы настраиваем минимальные настройки безопасности необходимые для работы инфраструктуры (firewall, security groups, централизованная авторизация и т.д.).
Если стоит задача, что нужно произвести более детальную настройку, то в ход идут инструменты описанные выше. Данные подходы используем, чтобы предотвратить возникновение проблемы на корню, а не ждать когда случить апокалипсис)
Данная статья более подходит не для крупных проектов. На своём опыте могу поделиться, что многие страдают проблемой нагрузки сервера от большого количества поисковых ботов. Для проекта их уровня на данный момент нет смысла покупать платные решения. Остаются лишь варианты создания уровней блокировки трафика своими силами, не каждая площадка в интернете имеет 1000-2000rps.
Для нормального сайта, с хорошей посещаемостью, даже при 1000-2000rps, легко получить много запросов с одного IP через мобильных провайдеров. Так что rate limit тоже вариант такой себе.
Данный способ показан лишь как один из вариантов реализации, как вы его осуществите уже зависит от вас.
Не надо делать if с перечислением, сделай лучше map. Когда надо будет добавить 16,17,... агент, задолбаешься проверять, есть ли такой уже в списке.
Если вас так пугают крупные логи, то вам поможет настройка ротации логов.
Если уж блокировать страны, то почему бы не делать это через iptables? Неужели так нравятся 10 гиговые логи nginx?
Так там и нет утверждений, что это ddos . Фраза "одним из отличительных признаков" я думаю прекрасно говорит об этом. Если у вас достаточно большое количество легитимного трафика поступает от пользователей и вы прекрасно знаете об этом, я думаю логика сравнительного анализа информации из логов на основании предыдущего интервала времени поможет вам в любом случае вычленить вредоносный IP, делать подобные выводы можно лишь на основе совокупности факторов, которые также прекрасно описаны выше.
4000 запросов за час? Это и близко не ddos, я столько от обычных клиентов получаю иногда
Прежде чем утверждать какую-либо информацию необходимо проверить со своей стороны можете ли вы осуществить скачивание базы по указанной ссылке. При проверке на текущий момент я не фиксирую каких-либо проблем. Но даже если они у вас и есть, я думаю вы можете прекрасно ознакомиться со статьями про VPN, которых за последнее время появилось не мало.
По указанной ссылке скачивается база MaxMind, а он запретил использовать свои базы в России с 25 апреля
Привет,
Работает весь этот процесс уже чуть больше года.
Вопрос хороший. В основе основ везде Debian 11, но сама freeipa развернута может быть только на ОС Centos, в нашем случае использовали Centos 8.
Везде есть свои сложности, меня лично функционал и работоспособность freeipa вполне радует, очень большие сложности были лишь при первичной инсталяции и при создании реплики.
Привет,
Информация обновлялась периодически каждые 60 секунд. О каких требованиях со стороны ИБ по уменьшению лага стоит вопрос? Как эти 2 момента связаны в контексте Информационной Безопасности подскажите пожалуйста?
Про бизнес-пользователей в рамках статьи речи не идёт, статья рассказывает лишь о внедрении возможных способов авторизации в продуктовую или тестовую среду для администраторов. С вопросом использования Keycloak для бизнес-пользователей пока честно говоря познакомиться не получилось, но насколько я знаю эти параметры стараются разделять точно на уровне Realm для того, чтобы как минимум структурно разделить извлекаемых или заведённых пользователей в keycloak.
Что касается времени жизни токенов как для администраторов, так и для бизнес-пользователей, то подразумеваю, что они могут и должны быть разными. А значения, которые необходимо выставить трактует и бизнес, и КБ.
Проблем с производительностью не было при извлечении как отдельной группы пользователей, так и всей архитектуры, но тут можно и явно отметить ряд условий нашей инфраструктуры.
1. Исходная freeipa имела всего 500 пользователей, но в ней также присутствовала сложная структура вложенности групп.
2. У нас везде имеется широкий запас по ресурсам.
3. Отличная и стабильная ширина канала на сетевом уровне.
Не проверялся данный момент, так как по стандартам имена пользователей only English.
По условию ТЗ таких требований отражено не было.
Этот вопрос на данный момент оформлен в виде задачи и он будет ещё решаться. Вопрос георепликации - это очень масштабная вещь и учитывая, что у нас закрытый контур - явно возникают проблемы связанные с сетью. Для поднятия георезерва как минимум нужно произвести долгое согласование с КБ и проработать новую архитектуру, учитывая все риски.
Статья не просто про то как настроить федерацию)
Вариантов решения задач авторизации существует очень много, главная проблема возникает, когда ты пытаешься разобрать все возможные вариант, учитывая что это должно быть безопасно, стабильно, удобно и актуально. Когда производилась настройка всех процессов и погружение в аспекты описанные выше, было страшное огорчение, что сама документация Keycloak не соответствует актуальным версиям своего ПО и возникают сложности в настройке всевозможных процессов.
Спасибо, тоже относительно не давно наткнулись на данный эскпортер, тестируем сейчас его работу, но хотелось бы всё же решение из коробки на уровне функционала Cloud Eye.
Привет, никто не говорит, что его нет) Хочется лишь сказать, что он не работает. Правила фаервола присутствуют на нодах, но свой функционал не выполняют.
Проводились работы, анализ проблемы и решения кроме описанного ранее, найдено не было.
Относительно вопроса с получением реальных ip адресов не совсем согласен. Использовали в ходе своих работ параметр obtain client ip и никаких дополнительных плагинов не требовалось.
Привет, спасибо за вопрос. Тут скорее требование со стороны заказчика, а не наше желание или выбор. Именно поэтому и решили описать проблемы, с которыми столкнулись и какие варианты решения были найдены.
По стандарту мы настраиваем минимальные настройки безопасности необходимые для работы инфраструктуры (firewall, security groups, централизованная авторизация и т.д.).
Если стоит задача, что нужно произвести более детальную настройку, то в ход идут инструменты описанные выше. Данные подходы используем, чтобы предотвратить возникновение проблемы на корню, а не ждать когда случить апокалипсис)
А в чём "оверкилл"?)
Уже писал выше, что это лишь один из вариантов реализации. Никто не запрещает его использовать как и применять map.
Да вы правы, спасибо. Данный момент был упущен. Скорректировали.
Данная статья более подходит не для крупных проектов. На своём опыте могу поделиться, что многие страдают проблемой нагрузки сервера от большого количества поисковых ботов. Для проекта их уровня на данный момент нет смысла покупать платные решения. Остаются лишь варианты создания уровней блокировки трафика своими силами, не каждая площадка в интернете имеет 1000-2000rps.
Данный способ показан лишь как один из вариантов реализации, как вы его осуществите уже зависит от вас.
Если вас так пугают крупные логи, то вам поможет настройка ротации логов.
Так там и нет утверждений, что это ddos . Фраза "одним из отличительных признаков" я думаю прекрасно говорит об этом. Если у вас достаточно большое количество легитимного трафика поступает от пользователей и вы прекрасно знаете об этом, я думаю логика сравнительного анализа информации из логов на основании предыдущего интервала времени поможет вам в любом случае вычленить вредоносный IP, делать подобные выводы можно лишь на основе совокупности факторов, которые также прекрасно описаны выше.
Прежде чем утверждать какую-либо информацию необходимо проверить со своей стороны можете ли вы осуществить скачивание базы по указанной ссылке. При проверке на текущий момент я не фиксирую каких-либо проблем. Но даже если они у вас и есть, я думаю вы можете прекрасно ознакомиться со статьями про VPN, которых за последнее время появилось не мало.