Как стать автором
Обновить

Комментарии 7

Правила пользования S-Terra, с. 15, для исполнения КС2 требуется АПМДЗ на аппаратную платформу (т.е. на виртуальную машину поставить нельзя). Как вы умудрились пройти аттестацию по К1 с криптошлюзом на виртуалке? =)
По требованиям регулятора для ГИС в качестве СЗИ необходимо рассматривать только сертифицированные решения, что очевидно. С другой стороны, на текущий момент нет действующего документа, определяющего требования к классу используемых криптосредств. Для ряда клиентов (в случаях повышенных требованиях описанных частных моделях нарушителя) мы можем рассмотреть использование необходимых ПАК с более высоким классом, чем КС1.
Подскажите пожалуйста как у Вас реализованны меры ЗСВ.5 и УПД.17, а в частности «Требования к усилению УПД.17»: 2) в информационной системе должна осуществляться доверенная загрузка уровня базовой системы ввода-вывода или уровня платы расширения, реализованные на основе программно-аппаратного модуля.
В защищенном сегменте Облака #CloudMTC на уровне технических средств мера ЗИ реализуется организационно-режимными мероприятиями и применением АПМДЗ на уровне платы расширения. Сожалею, но технические детали продукта не смогу привести из-за ограничений в политиках.

Хороший кейс, но больше теоретический. На практике необходимо под бэкапы держать отдельный выделенный канал связи. Ведь как только в канал и на шифратор попадëт трафик передачи бэкапа весь межцодный трафик "просядет". Это же касается и критических бизнес-сервисов. Под них так же необходимо ставить дополнительные vpn- шлюзы.

В нашем случае под бекапы установлены виртуальные криптошлюзы. Шириной канала, как и объемом передаваемых данных, конечно, можно и нужно управлять. Хочу отметить, что большинство наших клиентов не делает полный бекап каждый день. Ежедневные “дельты”, как правило, не большие по объемам и могут легко быть переданы.
Конечно, если появляется новый клиент с вопросами миграции (что потребует большой объем передачи данных), для такой задачи может быть развернут дополнительный виртуальный шлюз на время миграции. При этом мы и получаем плюсы использования виртуального шлюза – быстро развернул под задачу, использовал, и как только стал не нужен – выключил. При этом оплата, в отличие от ПАК только за лицензию на тот месяц или два что выполнялась миграция. Такой подход всем приятен;)

Алексей, здравствуйте. Прошу прщения что комментарий к старой теме, тем не менее уверен - ответ будет полезен для потенциальных клиентов.

Вопрос по сертификации СРК в частности и платформы в целом. Из данной статьи следует, что для РК используется решение от Veeam, так как кроме того что оно удобно (современно / молодёжно) ещё и имеет сертификат ФСТЭК. Дъяывол, как известно, в деталях. На сколько понимаю, на данный момент сертифицирована определенная и очень старая версия СРК (9-ая при активно развивающейся 11-ой). Как с этим возможно жить вообще? Ведь баги и дыры в безопасности находят и устраняют очень часто. И это мы только про СРК, а как быть с сертифицированным облаком (гипервизор, МСЭ, СЗИ, НСД и прочая обвязка), тут масштаб бедствия на порядок серьезнее. Как можно это принять, в наше неспокойное время? Страшнее всего то, что переезжая в сертифицированное (которое дороже обычного, к слову) облако обыватель надеется на более качественную защиту, а на деле получается ровно наоборот... Или я не прав и заблуждаюсь? Заранее благодарю за ответ!

Зарегистрируйтесь на Хабре , чтобы оставить комментарий