Comments 13
а также учетные данные, хранящиеся в переменных окружения.
а здесь-то что не так?
удалил.
У нас в jira есть тип тикета - развертывание нового сервиса. В одном из полей необходимо указать все переменные окружения. Если переменная содержит чувствительную информацию, например, пароль, то в тикете оставляем только имя, а значение передаём по другим каналам. В одном из тикетов значение такой переменной не удалили.
Обманом получил пользовательские данные для входа в Service Desk компании.
Ну то есть с каменного века ничего не поменялось: самое слабое звено — это ТЫ, %USERNAME%!
Интересный проект получился! Хотя и не покидает ощущение, что вам было даже более интересно в ML погрузиться, чем решить конкретно задачу мониторинга утечки "секретов" :)
В первую очередь мы начали искать готовое решение. Но оказалось, что готовых opensource-плагинов для Jira на этот случай нет. Поэтому мы решили написать свой с использованием Machine Learning и сделать его более универсальным, для подключения к различным источникам: Jira, Confluence, общие диски.
Если я правильно понял, то вы "по крону" дёргаете джировское API и запрашиваете список подходящих тикетов для проверки (новые или недавно отредактированные). Дальше анализируете их текст на предмет утечки секретов с последующим созданием алерта. Пробовали ли использовать для этого анализа существующие opensource-решения (trufflehog или аналоги)? Исследовали ли возможности Джиры и Конфлюенса на предмет предотвращения постинга туда секретов, может там есть аналог git хуков?
Все верно, у нас сейчас 2 сервиса, первый по "крону" (под капотом Quartz.NET) раз в несколько минут забирает из Jira api новые и измененные тикеты и комментарии за это время, после чего передает во второй сервис, который оценивает строку и выдает результат. Если сервис что-то нашел, мы сохраняем в БД номер тикета и хэш строки, для исключения повторного анализа и алертинга. На счет существующих решений - есть большое количество решений для git репозиториев, но именно для таск трекера находил несколько. Одни так же работали по API, забирая все тикеты по критериям (n0s1). Другие встраивались в Jira, но сканировали не в моменте создания тикета/написания комментария (security-for-jira), а по кнопке или расписанию. На счет запрета постинга со стороны Jira - я вижу только одну возможность, как мы можем запретить, это повесив проверку на момент создания тикета либо на этапе переходов состояния (например, New -> InProgress). Но тут есть сложности - это настраивается на каждом workflow а у нас их довольно много. Так же эта проверка не отработает, при написании комментария, либо после редактирования.
На счет существующих решений - есть большое количество решений для git репозиториев, но именно для таск трекера находил несколько
Но ведь вам по факту уже не так важна интеграция с Джирой, сколько просто анализ текста на наличие секретов. Вы же всё равно сами забираете текст нужных тикетов и потом отдаете в ваш анализатор. Поэтому и подумалось, что вам мог бы подойти и какой-то из существующих анализаторов, который умеет в stdin принимать текст или же просто текстовые файлики анализировать.
Но тут есть сложности - это настраивается на каждом workflow а у нас их довольно много. Так же эта проверка не отработает, при написании комментария, либо после редактирования.
Жаль. Выходит, что только мониторинг :(
Проект интересный, попадает в боли бизнеса.
Вопросики:
Судя по скриншотам Postman, сам сервис висит на http без авторизации. Достаточно ли "встать рядом и наблюдать за запросами", чтобы утащить из сырых данных очередной токен (в статье не раскрыт вопрос защиты самого сервиса на проде и не через Jira ли передавали токены от него)?
Можно ли лонгридом сломать сервис? Передача через GET обычно ограничена, скажем 8k, и если превысить, то текст пропустят?
Мне нужно такое же, но в redmine, поделитесь датасетом для обучения?))) /sarcasm
Скрины с локально запущенного экземпляра. В проде это все работает в k8s, и доступ между сервисами ограничен политиками сетевого доступа. Обычно в кубере терминация ssl на уровне ingress, теоретическая возможность прослушивания нешифрованного трафика внутри есть.
Хороший вопрос. Мы разбиваем тикет, комментарии и другие поля по символу переноса строки и отправляем разными запросами. Что будет, если в тикете появится на столько длинная строка без переносов - API выдаст 500 и эта строка будет пропущена. Спасибо, что подсветили этот момент, таких строк у нас еще не было, но заложим этот случай.
На старте проекта мы тоже искали готовые датасеты для обучения, но по понятным причинам их никто не публикует. Ну и мы не будем)
Легче и безопасней использовать статический Stopwatch.GetElapsedTime, даже для примеров, а не экземпляр класса Stopwatch :)
Возможно, вы правы, работаю со Stopwatch крайне редко. Но не вижу большой проблемы использовать его приватном поле объекта
private readonly Stopwatch _timer = new Stopwatch();я не создаю Stopwatch экземпляр при каждом вызове метода, а учитывая что экземпляры класса подключаю синглтоном
builder.Services.AddSingleton<RegexPredictor, RegexPredictor>();либо выбираю доступный экземпляр из пула
builder.Services.AddPredictionEnginePool<ModelInput, ModelOutput>()
.FromFile(filePath: "GeneralModel.mlnet", watchForChanges: true);экземпляр не будет часто пересоздаваться. Или есть другие причины?
Пароли в открытом доступе: ищем с помощью машинного обучения