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