Мы часто рассказываем о KasperskyOS — микроядерной ОС для подключенных к Интернету систем с особыми требованиями к кибербезопасности. И периодически получаем закономерный вопрос: а где можно пощупать эту вашу KasperskyOS? Поскольку на данный момент KasperskyOS является закрытой операционной системой, мы пока не готовы раскрыть ее исходный код. Однако всем, кому это интересно, можем предложить познакомиться с KasperskyOS Community Edition SDK (KasperskyOS CE SDK). В этом посте мы расскажем, из чего состоит SDK, и разберемся, как взаимодействовать с нашей операционной системой.

KasperskyOS CE SDK — это общедоступная версия KasperskyOS, разработанная с целью демонстрации основных принципов разработки безопасных решений. С помощью Community Edition SDK вы можете разрабатывать свои проекты, основываясь на подходе Secure by Design, то есть с учетом безопасности, заложенной в архитектуру решения.

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

Меня зовут Степан Охорзин, я Senior Go Developer в «Лаборатории Касперского». У нас в компании уже много проектов/продуктов, которые пишутся на Go, а еще мы мигрируем на него с «плюсов» там, где это возможно. Ведь Go — отличный язык, когда речь идет о распределенных системах; в частности, мы разрабатываем на нем облачные решения.

Сегодня речь пойдет как раз об одном из таких инструментов — Kaspersky Security Center (KSC). Если коротко, то KSC — это консоль для удобного управления безопасностью на уровне предприятия, эдакий аналог ЦУПа для сложных IT-систем. Как вы уже догадались, KSC построен на микросервисной архитектуре — и именно в нем мы организовали интеграционное тестирование. Теперь наши тесты не просто не уходят в технический долг, а могут сами служить документацией. Мы же думаем только о бизнес-логике, все остальные вопросы берет на себя DI-контейнер.

В статье расскажу, как мы это реализовали, с деталями и примерами.

Привет, Хабр! Меня зовут Михаил Килинский, я — Senior Developer в проекте Data Warehouse «Лаборатории Касперского». Наша команда строит хранилища данных и разрабатывает ETL- и ELT-процессы, мы пишем на Python, SQL и C# (.NET), а весь код находится в монорепозитории.

Гибкие методологии построения хранилищ данных — очень популярный тренд. Причина — возрастающая сложность корпоративных моделей данных и необходимость интеграции большого числа разнородных источников, которые включают в себя не только традиционные СУБД и плоские файлы, но и различные real-time-брокеры сообщений, внешние API и базы данных NoSQL.

В этой статье хочу рассказать, как мы изначально хранили данные, почему решили внедрить методологии Data Lake и Data Vault и к чему это привело. Кроме того, покажу, как мы изобрели свой велосипед разработали свой фреймворк по автоматизации работы с помощью модели Data Vault.

Сегодня дизайн-система — это неотъемлемая часть процесса разработки цифровых продуктов. Однако не всегда очевидно, как именно такой инструмент помогает работать с UI-компонентами и улучшать качество продукта.

Меня зовут Артур Иванов, я тимлид B2B Product Design департамента Design & Research Office (DRO) «Лаборатории Касперского», и именно перед нашей командой встал вызов по внедрению дизайн-системы под названием Hexa UI в уже существующие рабочие процессы отдела дизайна.