ГОСТ 57580.1 — это национальный стандарт безопасности банковских и финансовых операций. Стандарт был введен в действие 1 января 2018 года и стал обязательным для всех кредитных и некредитных финансовых организаций.

А теперь давайте разберемся, что это за стандарт, как он помогает и почему его автоматизированная оценка и отчётность – это не только полезно, но и выгодно.

ГОСТ 57580.1: Введение

ГОСТ 57580.1 – это стандарт, который определяет требования к защите персональных данных в информационных системах. Если бы у ваших данных были страховки, ГОСТ 57580 был бы самым надёжным страховым агентом. Он устанавливает правила, которые помогают избежать неприятных инцидентов и обеспечивают сохранность информации.

Отчётность: Зачем и как?

Теперь перейдем к отчетности. Представьте, что вы пришли на ежегодный осмотр к врачу. Он измеряет ваш вес, рост, проверяет сердце и другие важные показатели. Отчётность в рамках ГОСТ 57580 – это такой же осмотр, но для вашей системы информационной безопасности.

Почему это важно?

1. Прозрачность. Отчеты показывают, где вы находитесь на пути к соответствию стандарту. 

2. Контроль и улучшение. На основании отчетов можно вносить улучшения. 

3. Документирование. Если вдруг появится необходимость доказать, что вы соответствуете стандарту, отчеты станут вашими доказательствами. 

Как это работает?

Автоматизированная оценка соответствия – это как тренажерный зал для вашей безопасности. Она проверяет, соответствуют ли ваши системы требованиям ГОСТ 57580, и подсказывает, где нужно подтянуться. Ваши системы проходят через серию тестов и проверок, чтобы убедиться, что они в отличной форме и готовы к любым вызовам.

В данной статье я опишу процесс создания умного кухонного крана. Я инженер по инновационным продуктам и методология создания инновационных продуктов была в полной мере применена в этом изделии.

Привет, хабр! Я технический писатель в компании Bimeister. 

Наша компания занимается разработкой программного обеспечения для автоматизации крупных производств. Вместе с тем мы разрабатываем большой объем технической и проектной документации. Так получилось, что Заказчики наших продуктов стремятся к соблюдению требований государственных стандартов (далее — ГОСТ), поэтому всю отчетную документацию мы пишем в соответствии со стандартами.

Кажется, что все достаточно просто — пишешь по ГОСТ, и все остаются довольны. Но, как показывает практика, не всё так однозначно как должно быть в документах уровня ГОСТ, и у каждого Заказчика есть свое видение относительно требований стандартов, под которое нам приходится подстраиваться.

Требования Заказчика будут проходить красной нитью по всей статье, поэтому сразу приведу цитату, которая успокаивает мне нервы в такие моменты:

Существуют ли альтернативы Figma? Обзор основных конкурентов. Есть ли те, которые способны потеснить дизайн-гегемона с первого места?

Всем доброе утро! С Вами Крылов Александр, и мы продолжаем серию статей про DevOps as a Service, и как с помощью данного подхода возможно решить ряд распространённых проблем в организации работы подразделения. В прошлых статьях мы описали подход и показали пути решения часто встречающихся проблем. С данными материалами можно ознакомиться тут Часть1, Часть2, Часть 3, Часть 4. Сегодня мы обсудим совмещение нескольких подходов для управления сквозным бэклогом команды.

Итак, проблема, которую мы будем решать — это отсутствие процесса работы с бэклогом и сквозной приоритизацией. Важно отметить, что инструменты, которыми я буду в основном оперировать, — это jira инсталляции server, плагин jira structure, jira kanban. Если реализация возможна на других инструментах, я буду в явном виде на них ссылаться. Но думаю, что в том или ином виде, подход можно переиспользовать и для других тикетных систем.

Приветствую моих читателей! Меня зовут Екатерина. Ранее 3.5 года я администрировала bpm-систему, сейчас вот уже более двух лет я работаю системным аналитиком и развиваю нашу собственную bpm-систему. В данной статье хочу рассказать о дилемме, с которой столкнулись я и моя команда.

Немного познакомлю вас с тем, над чем мы работаем — BPMS (система для управления бизнес-процессами, в основе которой лежит BPMN). Движок полностью разработан специалистами компании. Фронтовая часть реализована на основе библиотеки bpmn.io, с доработкой логики, специфичной для внутренних задач. В этой библиотеке представлен широкий выбор элементов, но у нас своя обёртка над ней — bpmn-editor, в которой мы открываем элементы для пользователей по мере проработки логики их автоматизации.

Немного о той части системы, над которой работаю я:

Всем привет, я разработчик из компании Bimeister и я хочу рассказать о шаблонном C# сервисе, который мы создали, чтобы унифицировать наши приложения и сократить время работы разработчиков над базовой настройкой приложения.

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

Для решения этой задачи Microsoft создала возможность делать свои шаблоны приложений для .net. Он представляет из себя обычный проект на C#, который можно упаковать в nuget пакет.

Перво-наперво необходимо определиться с архитектурой приложения, какой подход, какие паттерны будем использовать. Для вдохновения мы смотрели на пример от Microsoft https://github.com/dotnet/eShop.