Да, с персональным токеном Maintainer вы правы. В GitLab нельзя считать PAT полноценным способом понизить права пользователя. Токен в существенной части наследует полномочия самой identity. Если Maintainer имеет право пушить в protected branch, передача агенту его личного PAT эту проблему не решает.
Но для меня это как раз аргумент против передачи агенту личного токена, а не против отдельной identity агента.
Если задача агента только читать репозиторий для разбора тикета, права на push у него вообще не должно быть. Это обычный least privilege.
Если агенту действительно нужно создавать изменения, я бы разделял две identity:
"человек = Maintainer"
"агент = отдельный bot/service account с Developer или более узкими правами"
Дальше protected branch можно настроить так, чтобы прямой push туда был запрещен, а изменения шли через отдельную ветку и merge request. Тогда агент не наследует Maintainer-права человека, который его запустил.
И здесь есть важная разница между двумя формулировками:
«операция должна быть связана с конкретным сотрудником»
и
«операция должна выполняться от имени этого сотрудника».
Первое обязательно. Второе, на мой взгляд, для агента опасно.
Мы знаем, какой сотрудник инициировал действие, но агент при этом не изображает этого сотрудника и не получает автоматически весь его набор прав.
Идеальная схема еще уже: агент получает полномочия под конкретную задачу и на ограниченное время. GitLab сам по себе не всегда позволяет сделать такой downscope для каждого Git-действия, поэтому в чувствительных сценариях понадобится дополнительный authorization broker или gateway.
Так что ваше замечание про Maintainer PAT я бы принял полностью. Более того, это хороший пример того, почему отдельная идентичность агента нужна не для красоты в логах, а как реальная граница безопасности.
Да, здесь замечание по делу. В описанной конфигурации одного ограничения egress до репозитория и тикетницы недостаточно. Если тикетница сама является разрешённым каналом записи, скомпрометированный агент вполне может использовать её для эксфильтрации данных.
То есть мой пример получился слабее самого принципа.
«Минимальные привилегии» и «презумпция взлома» я бы при этом не противопоставлял. Первое скорее один из механизмов реализации второго. Если мы действительно предполагаем, что агент рано или поздно проглотит prompt injection, надо проектировать права так, чтобы даже уже скомпрометированный агент не получил большой blast radius.
В вашем примере недостаточно разрешить ему только Git и тикетницу. Надо ещё ограничивать сами capabilities: конкретный репозиторий, конкретные paths, конкретный проект или тикет, отдельное право на запись и, в идеале, контроль того, какие данные вообще могут переходить из repo в ticket. Иначе две по отдельности легальные операции read repo и write ticket складываются в совершенно легальный с точки зрения ACL канал утечки.
С личными токенами сотрудников я бы, наоборот, не согласился.
Требование ИБ «операция должна быть связана с конкретным сотрудником» разумное. Но из него не следует, что агент должен работать под постоянным личным токеном этого сотрудника.
Мне кажется более здоровой схема:
user → конкретный run → короткоживущие downscoped credentials → agent
Тогда в аудите остаётся и инициатор, и агент, и конкретный запуск, но агент не получает весь объём постоянных прав человека и не выглядит в логах как сам человек.
Так что да: пример в статье я бы после вашего комментария уточнил. Default deny по сети сам по себе здесь не является достаточной реализацией «презумпции взлома». Нужен ещё контроль сочетания разрешённых возможностей и потоков данных между ними.
Коллеги из Ideco, спасибо за мониторинг рынка. Всегда полезно увидеть себя на общей карте. Действительно, Traffic Inspector Next Generation часто работает в сегменте SMB, и мы этим гордимся. Нас выбирают, когда нужна не просто коробка NGFW, а в случае нестандартных сценариев, где важна гибкость настройки и низкая стоимость владения для небольших, но требовательных организаций. Что касается "статус неизвестен". Мы существуем на рынке более 20 лет (в разных ипостасях), имеем действующий сертификат ФСТЭК и внедрения не только в SMB, но и в сегменте среднего бизнеса (порой там, где тяжелые NGFW избыточны). Так что с определением "нишевый" мы, пожалуй, согласны. Ниша — это про фокус и экспертизу в решении конкретных задач клиента. Мы сфокусированы на тех, кому нужен предсказуемый, надежный и честный продукт без переплаты за звание лидера рынка.
Ava256, вот описание функционала Traffic Inspector Next Generation, включая межсетевой экран: https://ting-docs.smart-soft.ru/index.html# Хотя про коленки вам, конечно, виднее ;)
В TING был раньше и сейчас есть ещё один вариант двухфакторной аутентификации. Это расширенная аутентификация, в рамках которой пользователь вводит не только свой постоянный пароль от локальной учетной записи, но и ограниченный по сроку действия одноразовый пароль (Time-based One-Time Password).
«Лаборатория Касперского» сделала под этот проект интересный тест: ideas.kaspersky.com Нужно угадать по описанию идеи, выстрелила ли она или бизнес провалился
«А pfsense на этой железке, не знаете, какую будет иметь производительность?» Есть предположение, что также.
«Бывают ли дистрибутивы у этого производителя ''на попробовать'' покрутить?» — вот тут: www.smart-soft.ru/products/ting есть кнопка «Попробовать бесплатно»
«А вот этот файл testTI.pcap он что содержит, примеры каких-то атак?»
В трафике testTI.pcap использовалась атака типа «Фрагментированные пакеты» jolt2 (http://www.securiteam.com/exploits/5RP090A1UE.html) и targa3 (https://packetstormsecurity.com/DoS/targa3.c).
+ нагрузка из iperf + ping
" Его можно как-то использовать у себя?" — попробуйте:)
По сути своей TING это OPNsense с добавленными проприетарными плагинами от вендора + локализация + есть сертифицированная версия ФСТЭК. Другие авторы про это писали подробно, вот например habr.com/company/smart_soft/blog/350964
Признаться, я в основном работал со IDS snort и не сталкивался в нем с поддержки cuda, поэтому не обратил внимание на данную особенность. По поводу pf_ring суждение сложное, все зависит от количества экземпляров запускаемой suricata. Возможно стоило поиграться в данном направлении. Предложение по pf_ring это просто предложение, окончательное решение прежде всего за разработчиком оборудования.
Да, с персональным токеном Maintainer вы правы. В GitLab нельзя считать PAT полноценным способом понизить права пользователя. Токен в существенной части наследует полномочия самой identity. Если Maintainer имеет право пушить в protected branch, передача агенту его личного PAT эту проблему не решает.
Но для меня это как раз аргумент против передачи агенту личного токена, а не против отдельной identity агента.
Если задача агента только читать репозиторий для разбора тикета, права на push у него вообще не должно быть. Это обычный least privilege.
Если агенту действительно нужно создавать изменения, я бы разделял две identity:
"человек = Maintainer"
"агент = отдельный bot/service account с Developer или более узкими правами"
Дальше protected branch можно настроить так, чтобы прямой push туда был запрещен, а изменения шли через отдельную ветку и merge request. Тогда агент не наследует Maintainer-права человека, который его запустил.
И здесь есть важная разница между двумя формулировками:
«операция должна быть связана с конкретным сотрудником»
и
«операция должна выполняться от имени этого сотрудника».
Первое обязательно. Второе, на мой взгляд, для агента опасно.
В audit trail вполне можно сохранить:
"initiated_by = employee"
"executed_by = agent/service account"
"task/run = конкретный запуск"
Мы знаем, какой сотрудник инициировал действие, но агент при этом не изображает этого сотрудника и не получает автоматически весь его набор прав.
Идеальная схема еще уже: агент получает полномочия под конкретную задачу и на ограниченное время. GitLab сам по себе не всегда позволяет сделать такой downscope для каждого Git-действия, поэтому в чувствительных сценариях понадобится дополнительный authorization broker или gateway.
Так что ваше замечание про Maintainer PAT я бы принял полностью. Более того, это хороший пример того, почему отдельная идентичность агента нужна не для красоты в логах, а как реальная граница безопасности.
Да, здесь замечание по делу. В описанной конфигурации одного ограничения egress до репозитория и тикетницы недостаточно. Если тикетница сама является разрешённым каналом записи, скомпрометированный агент вполне может использовать её для эксфильтрации данных.
То есть мой пример получился слабее самого принципа.
«Минимальные привилегии» и «презумпция взлома» я бы при этом не противопоставлял. Первое скорее один из механизмов реализации второго. Если мы действительно предполагаем, что агент рано или поздно проглотит prompt injection, надо проектировать права так, чтобы даже уже скомпрометированный агент не получил большой blast radius.
В вашем примере недостаточно разрешить ему только Git и тикетницу. Надо ещё ограничивать сами capabilities: конкретный репозиторий, конкретные paths, конкретный проект или тикет, отдельное право на запись и, в идеале, контроль того, какие данные вообще могут переходить из repo в ticket. Иначе две по отдельности легальные операции
read repoиwrite ticketскладываются в совершенно легальный с точки зрения ACL канал утечки.С личными токенами сотрудников я бы, наоборот, не согласился.
Требование ИБ «операция должна быть связана с конкретным сотрудником» разумное. Но из него не следует, что агент должен работать под постоянным личным токеном этого сотрудника.
Мне кажется более здоровой схема:
user → конкретный run → короткоживущие downscoped credentials → agentТогда в аудите остаётся и инициатор, и агент, и конкретный запуск, но агент не получает весь объём постоянных прав человека и не выглядит в логах как сам человек.
Так что да: пример в статье я бы после вашего комментария уточнил.
Default denyпо сети сам по себе здесь не является достаточной реализацией «презумпции взлома». Нужен ещё контроль сочетания разрешённых возможностей и потоков данных между ними.Коллеги из Ideco, спасибо за мониторинг рынка. Всегда полезно увидеть себя на общей карте. Действительно, Traffic Inspector Next Generation часто работает в сегменте SMB, и мы этим гордимся. Нас выбирают, когда нужна не просто коробка NGFW, а в случае нестандартных сценариев, где важна гибкость настройки и низкая стоимость владения для небольших, но требовательных организаций.
Что касается "статус неизвестен". Мы существуем на рынке более 20 лет (в разных ипостасях), имеем действующий сертификат ФСТЭК и внедрения не только в SMB, но и в сегменте среднего бизнеса (порой там, где тяжелые NGFW избыточны).
Так что с определением "нишевый" мы, пожалуй, согласны. Ниша — это про фокус и экспертизу в решении конкретных задач клиента. Мы сфокусированы на тех, кому нужен предсказуемый, надежный и честный продукт без переплаты за звание лидера рынка.
Ava256, вот описание функционала Traffic Inspector Next Generation, включая межсетевой экран: https://ting-docs.smart-soft.ru/index.html# Хотя про коленки вам, конечно, виднее ;)
WebRTC можно добавить в исключения. При этом возможность заблокировать или разрешить какие-то ресурсы есть на уровне ip/порта.
WebRTC не поддерживает, увы, ни Squid, ни 3proxy.
Протоколы RADIUS и LDAP
https://ting-docs.smart-soft.ru/proxy_multifactor.html
В TING был раньше и сейчас есть ещё один вариант двухфакторной аутентификации. Это расширенная аутентификация, в рамках которой пользователь вводит не только свой постоянный пароль от локальной учетной записи, но и ограниченный по сроку действия одноразовый пароль (Time-based One-Time Password).
Ой, не всё так просто. "Взяли" в соответствии с лицензионными условиями, поделились и продолжаем делиться результатами своей работы с сообществом: https://habr.com/ru/company/smart_soft/blog/350964/
Наше упущение! Уже занимаемся этим.
Просто мы очень любим логотип ТИНГа :)
«Бывают ли дистрибутивы у этого производителя ''на попробовать'' покрутить?» — вот тут: www.smart-soft.ru/products/ting есть кнопка «Попробовать бесплатно»
«А вот этот файл testTI.pcap он что содержит, примеры каких-то атак?»
В трафике testTI.pcap использовалась атака типа «Фрагментированные пакеты» jolt2 (http://www.securiteam.com/exploits/5RP090A1UE.html) и targa3 (https://packetstormsecurity.com/DoS/targa3.c).
+ нагрузка из iperf + ping
" Его можно как-то использовать у себя?" — попробуйте:)