Как да се сприятеляваме с GOST R 57580 и виртуализация на контейнери. Отговорът на Централната банка (и нашите съображения по този въпрос)

Неотдавна извършихме друга оценка на съответствието с изискванията на GOST R 57580 (наричан по-долу просто GOST). Клиентът е фирма, която разработва система за електронни разплащания. Системата е сериозна: повече от 3 милиона потребители, повече от 200 хиляди транзакции дневно. Там се отнасят много сериозно към информационната сигурност.

По време на процеса на оценка клиентът небрежно обяви, че отделът за разработка, в допълнение към виртуалните машини, планира да използва контейнери. Но с това, добави клиентът, има един проблем: в GOST няма нито дума за същия Docker. Какво трябва да направя? Как да оценим сигурността на контейнерите?

Вярно е, GOST пише само за хардуерна виртуализация - за това как да защитите виртуални машини, хипервизор и сървър. Потърсихме разяснение от Централната банка. Отговорът ни озадачи.

GOST и виртуализация

Като начало, нека си припомним, че GOST R 57580 е нов стандарт, който определя „изискванията за осигуряване на информационна сигурност на финансовите организации“ (FI). Тези ФИ включват оператори и участници в платежни системи, кредитни и некредитни организации, оперативни и клирингови центрове.

От 1 януари 2021 г. FI са длъжни да провеждат оценка на съответствието с изискванията на новия GOST. Ние, ITGLOBAL.COM, сме одиторска компания, която извършва такива оценки.

GOST има подраздел, посветен на защитата на виртуализирани среди - № 7.8. Терминът „виртуализация“ не е посочен там, няма разделение на хардуерна и контейнерна виртуализация. Всеки ИТ специалист ще каже, че от техническа гледна точка това е неправилно: виртуална машина (VM) и контейнер са различни среди, с различни принципи на изолация. От гледна точка на уязвимостта на хоста, на който са разположени VM и Docker контейнерите, това също е голяма разлика.

Оказва се, че оценката на информационната сигурност на VM и контейнерите също трябва да бъде различна.

Нашите въпроси към Централната банка

Изпратихме ги до отдела за информационна сигурност на Централната банка (представяме въпросите в съкратен вид).

1. Как да вземем предвид виртуални контейнери тип Docker, когато оценяваме съответствието с GOST? Правилно ли е да се оцени технологията в съответствие с подраздел 7.8 от GOST?
2. Как да оценим инструментите за управление на виртуални контейнери? Възможно ли е да ги приравним към компонентите за виртуализация на сървъра и да ги оценим според същия подраздел на GOST?
3. Трябва ли отделно да оценявам сигурността на информацията в контейнерите на Docker? Ако е така, какви предпазни мерки трябва да се вземат предвид по време на процеса на оценка?
4. Ако контейнеризацията се приравнява на виртуална инфраструктура и се оценява съгласно подраздел 7.8, как се изпълняват изискванията на GOST за внедряване на специални инструменти за информационна сигурност?

Отговорът на централната банка

По-долу са основните откъси.

„GOST R 57580.1-2017 установява изисквания за прилагане чрез прилагане на технически мерки във връзка със следните мерки ZI, подраздел 7.8 на GOST R 57580.1-2017, които, по мнение на отдела, могат да бъдат разширени до случаи на използване на виртуализация на контейнери технологии, като се има предвид следното:

• прилагането на мерки ZSV.1 - ZSV.11 за организиране на идентификация, удостоверяване, оторизация (контрол на достъпа) при внедряване на логически достъп до виртуални машини и сървърни компоненти за виртуализация може да се различава от случаите на използване на технология за виртуализация на контейнери. Като се има предвид това, за да се приложат редица мерки (например ZVS.6 и ZVS.7), считаме, че е възможно да се препоръча на финансовите институции да разработят компенсаторни мерки, които ще преследват същите цели;
• прилагането на мерки ZSV.13 - ZSV.22 за организиране и контрол на информационното взаимодействие на виртуални машини предвижда сегментиране на компютърната мрежа на финансова организация за разграничаване на обекти за информатизация, които прилагат технология за виртуализация и принадлежат към различни вериги за сигурност. Като вземем това предвид, ние вярваме, че е препоръчително да се осигури подходящо сегментиране при използване на технология за виртуализация на контейнери (както по отношение на изпълними виртуални контейнери, така и по отношение на системи за виртуализация, използвани на ниво операционна система);
• изпълнението на мерките ZSV.26, ZSV.29 - ZSV.31 за организиране на защитата на изображения на виртуални машини следва да се извършва по аналогия и с цел защита на основните и текущи изображения на виртуални контейнери;
• прилагането на мерки ZVS.32 - ZVS.43 за записване на събития за сигурност на информацията, свързани с достъпа до виртуални машини и компоненти за виртуализация на сървъри, трябва да се извършва по аналогия и по отношение на елементи от средата за виртуализация, които прилагат технология за виртуализация на контейнери.“

Какво означава това

Два основни извода от отговора на отдела за информационна сигурност на Централната банка:

• мерките за защита на контейнерите не се различават от мерките за защита на виртуални машини;
• От това следва, че в контекста на информационната сигурност Централната банка приравнява два вида виртуализация - Docker контейнери и VM.

В отговора се споменават и „компенсаторни мерки“, които трябва да бъдат приложени за неутрализиране на заплахите. Просто не е ясно какви са тези „компенсаторни мерки“ и как да се измери тяхната адекватност, пълнота и ефективност.

Какво не е наред с позицията на Централната банка?

Ако използвате препоръките на Централната банка по време на оценка (и самооценка), трябва да разрешите редица технически и логически трудности.

• Всеки изпълним контейнер изисква инсталиране на софтуер за защита на информацията (IP) върху него: антивирусен софтуер, мониторинг на целостта, работа с регистрационни файлове, DLP системи (предотвратяване на изтичане на данни) и т.н. Всичко това може да се инсталира на VM без проблем, но в случай на контейнер инсталирането на информационна сигурност е абсурден ход. Контейнерът съдържа минималното количество „комплект за тяло“, което е необходимо за функционирането на услугата. Инсталирането на SZI в него противоречи на смисъла му.
• Изображенията на контейнерите трябва да бъдат защитени по същия принцип; как да се приложи това също не е ясно.
• GOST изисква ограничаване на достъпа до компонентите за виртуализация на сървъра, т.е. до хипервайзора. Какво се счита за сървърен компонент в случая на Docker? Това не означава ли, че всеки контейнер трябва да се изпълнява на отделен хост?
• Ако за конвенционалната виртуализация е възможно да се разграничат VM чрез контури на сигурност и мрежови сегменти, тогава в случай на Docker контейнери в рамките на един и същ хост, това не е така.

На практика е вероятно всеки одитор да оцени сигурността на контейнерите по свой начин, въз основа на собствените си знания и опит. Е, или изобщо не го оценявайте, ако няма нито едното, нито другото.

За всеки случай ще добавим, че от 1 януари 2021 г. минималният резултат трябва да бъде не по-нисък от 0,7.

Между другото, ние редовно публикуваме отговори и коментари от регулатори, свързани с изискванията на GOST 57580 и наредбите на централната банка в Телеграм канал.

Какво да правя

Според нас финансовите организации имат само два варианта за решаване на проблема.

1. Избягвайте внедряването на контейнери

Решение за тези, които са готови да си позволят да използват само хардуерна виртуализация и в същото време се страхуват от ниски оценки според GOST и глоби от Централната банка.

плюс: по-лесно е да се спазват изискванията на подраздел 7.8 от GOST.

минус: Ще трябва да изоставим нови инструменти за разработка, базирани на виртуализация на контейнери, по-специално Docker и Kubernetes.

2. Откажете да спазвате изискванията на подраздел 7.8 от GOST

Но в същото време прилагайте най-добрите практики за осигуряване на информационна сигурност при работа с контейнери. Това е решение за тези, които ценят новите технологии и възможностите, които предоставят. Под „най-добри практики“ имаме предвид приетите в индустрията норми и стандарти за гарантиране на сигурността на Docker контейнерите:

• сигурност на хост ОС, правилно конфигурирано логване, забрана за обмен на данни между контейнери и т.н.;
• използване на функцията Docker Trust за проверка на целостта на изображенията и използване на вградения скенер за уязвимости;
• Не трябва да забравяме за сигурността на отдалечения достъп и мрежовия модел като цяло: атаки като ARP-spoofing и MAC-flooding не са отменени.

плюс: няма технически ограничения за използването на виртуализация на контейнери.

минус: има голяма вероятност регулаторът да накаже за неспазване на изискванията на GOST.

Заключение

Нашият клиент реши да не се отказва от контейнерите. В същото време той трябваше значително да преразгледа обхвата на работата и времето на прехода към Docker (те продължиха шест месеца). Клиентът много добре разбира рисковете. Той също така разбира, че по време на следващата оценка на съответствието с GOST R 57580 много ще зависи от одитора.

Какво бихте направили в тази ситуация?

Източник: www.habr.com