У нас есть модель нарушителя для каждого сегмента, в каждой модели определены возможности нарушителей и имеется вывод о классе необходимых к применению криптосредств для защиты ПДн. Соответственно, клиентам, которые размещают в нашем облаке свои ИСПДн, предоставляются сертифицированные ФСБ России СКЗИ для организации ГОСТ VPN.
При этом есть клиенты, которые размещают в нашем облаке системы, не являющиеся ИСПДн. Соответственно, обработки ПДн нет, а значит, защиту каналов связи они могут организовывать, как они считают правильным.
В итоге получаем следующее: те, у кого есть ПДн, защищают каналы связи с использованием ГОСТ VPN, те, у кого нет ПДн, защищают, как считают правильным.
Все действия по удаленному администрированию облачной платформы осуществляются через ГОСТ VPN, как показано на схеме в статье.
Полагаем, из таблички в статье это было не очевидно. Надеемся, это пояснение поможет.
Во-первых, согласно ФЗ «О техническом регулировании» подтверждение соответствия может проводиться не только в форме сертификации. Во-вторых, для защиты персональных данных не всегда должны применяться сертифицированные СЗИ. В п.4 Приказа ФСТЭК 21 указано: «Меры по обеспечению безопасности персональных данных реализуются в том числе посредством применения в информационной системе средств защиты информации, прошедших в установленном порядке процедуру оценки соответствия, в случаях, когда применение таких средств необходимо для нейтрализации актуальных угроз безопасности персональных данных».
Нет, вообще, опечатки не было, всё верно. Объясняем: при необходимости организуется ГОСТ шифрование, это не проблема. Но в нашем сегменте «Защищенный» могут размещаться еще системы, не являющиеся ИСПДн (например, обычные коммерческие системы). Тут требование по сертифицированным СКЗИ (ГОСТ VPN) не применимо.
Добрый день! Спасибо за ваши вопросы. По первому пункту стоит вообще отдельный материал писать. В одном из следующих постов осветим эту тему. А по второму всё просто: мы используем выделенный канал, поэтому там проблем с DDoS быть не может
Из книжек последнее, что стоит прочитать — «Mastering Non-Functional Requirements» (правда, как говорит Александр, в той версии, что он читал, редактор проспал зарплату, и было грустно:)). Также рекомендуем курсы Coursera: «Making Architecture», IEBusiness School; «Planning, Auditing and Maintaining Enterprise Systems», Colorado University.
Спасибо за мысль! Если мы найдём такой отдельный и без NDA, сделаем отдельный пост и попробуем объяснить, что, откуда и почему взялось. Однако, кажется, далеко не любой бизнес-заказчик хотел бы это увидеть. Скорее, наоборот, слишком уж много данных на входе, которые мало кому снаружи надо знать.
Как говорит Александр, ему было бы не очень комфортно переходить с изменением типа задач на другое место работы. Гораздо проще погружаться в новое в приятном и привычном коллективе. Но при этом считает, что тут все варианты возможны. Было бы желание
Тимлид это вообще одна только голая системность. В смысле, способность справляться со сложностями, которые все время экспоненциально растут. Когда ты программист, ты пишешь код, когда ты тимлид, приходится подбирать людей, смиряться с разными способами мышления, выстраивать коммуникацию внутри команды, параллельно «обрастая» трекерами, вики, досками и CI. Если это не драйв, то что же тогда? Вообще, спасибо вам за хорошую мысль! Чуть позже мы соберем побольше материала и постараемся рассказать обо всех трудовых реалиях в предложенном разрезе.
Да, прям так и дали. Да, понимали почти всё — задавали уточняющие вопросы, где неясно. Судя по подобранным резюме, всё поняли хорошо: по фронтендщикам совершенно левых резюме не было. А сами кандидаты всё понимали, мы проверили.
Да, спасибо. Это основной сайт «Техносерва», увидели глюк (возник при блокировке swf) и уже исправили. Мы сейчас полностью будем менять отображение баннеров, чтобы подобное не могло возникнуть в дальнейшем.
Тестировщиков у нас нет, в этой роли попеременно выступают разработчик фронта, тимлид (Петр), аналитик и коллеги из службы эксплуатации. Аналитик делает первичную приемку по use-кейсам, которые он для нас разработал, после него или вместе с ним бизнес-заказчики тестируют то, что поменялось. Еще мы запускаем selenium-тесты интерфейса основных сценариев.
Поэтому пока все эти специалисты тестируют, разработчики получают от мониторинга «алерты» и логи ошибок (от фронта и от бекенда), и видят, «падает» что-то или нет, даже если это незаметно для тестирующих
hosher, процесс такой: пишем автотесты, когда все тесты проходят, разворачиваем новую версию на тестовом стенде. Там уже новые «фичи» тестирует вручную аналитик, а бизнес-заказчики вносят дополнения. Перед релизом новую версию всегда проверяет служба эксплуатации.
box4, с серверов windows мы собираем только события системных журналов, используем winlogbeat.
Если у вас задача собирать логи с файловой системы или напрямую из базы данных, смотрите в сторону filebeat и jdbc-input плагина для Logstash.
box4, Спланк рассматривали как возможный вариант, но ELK в нашем случае оказался наиболее подходящим продуктом с точки зрения предоставляемых возможностей и стоимости внедрения. Отвечая на второй вопрос, на данный момент ежедневно мы получаем 1-2 ГБ новых логов.
Mordva_givi, спасибо, что читаете нас! Внутри аттестованного сегмента изоляция заказчиков происходит на уровне VMware. По запросу заказчиков также можем выполнять частные проекты — строить физически отдельные сегменты (частные облака в нашем дата-центре).
olku, спасибо, что читаете нас! Мы говорим об одной из идей в подходе к управлению сервисами Site Reliability Engineering (SRE) — «бюджете простоев». Для реализации этой идеи нужны система мониторинга и ITSM-система, в качестве которой мы рассматриваем ServiceNow.
При этом есть клиенты, которые размещают в нашем облаке системы, не являющиеся ИСПДн. Соответственно, обработки ПДн нет, а значит, защиту каналов связи они могут организовывать, как они считают правильным.
В итоге получаем следующее: те, у кого есть ПДн, защищают каналы связи с использованием ГОСТ VPN, те, у кого нет ПДн, защищают, как считают правильным.
Все действия по удаленному администрированию облачной платформы осуществляются через ГОСТ VPN, как показано на схеме в статье.
Полагаем, из таблички в статье это было не очевидно. Надеемся, это пояснение поможет.
Поэтому пока все эти специалисты тестируют, разработчики получают от мониторинга «алерты» и логи ошибок (от фронта и от бекенда), и видят, «падает» что-то или нет, даже если это незаметно для тестирующих
Если у вас задача собирать логи с файловой системы или напрямую из базы данных, смотрите в сторону filebeat и jdbc-input плагина для Logstash.