Все больше компаний начинают переходить на Kubernetes (не важно внутренний или managed в облаке) или по крайней мере присматриваться к нему. Логично что в начале возникает вопрос: а с чего необходимо начать формирование его безопасности?
Перво-наперво необходимо, чтобы в интернет не смотрело то, чего туда смотреть не должно). Данные misconfigurations чрезвычайно просто и быстро находятся удаленными злоумышленниками со всего Мира с помощью сканирования портов буквально в течение нескольких минут после деплоя.
Далее идут всем хорошо известные встроенные механизмы безопасности Kubernetes. НО нужно помнить, что в каждой компании Kubernetes уникален почти как снежинка, от компании к компании разные подходы к разработке, культура/процессы работы/разработки, в конце концов разные продукты/сервисы и, конечно, же уровень зрелости в вопросах информационной безопасности.
Поэтому чужие success story о использовании того или иного инструмента или подхода могут быть совершенно не эффективны или не применимы для вас.
Инструменты/подходы должны не латать дыры, а выстраивать правильный процесс (не забываем, что безопасность — это не состояние, а процесс!) внутри компании. Так на пример использование самого крутого инструмента поиска/анализа инцидентов будет совершенно не эффективным, если команда безопасности будет утопать в этих же инцидентах, не успевая их разбирать.
Подход при котором для решение проблемы "A", возьмем решение "X", для решения проблемы "B" возьмем решение "Z" и т.д. далеко не всем по карману и в условиях быстро трансформирующегося современного бизнеса не эффективен на длинных дистанциях.
Поэтому выстраивайте процессы, а не состояния безопасности и перед тем, как что-то внедрять разбирайтесь в том что и как у вас работает/устроено внутри. Иначе внедрением почти любого security механизма можно очень легко что-то сломать … А знакомство с безопасностью должно быть приятным, а не отталкивающим =)
Перво-наперво необходимо, чтобы в интернет не смотрело то, чего туда смотреть не должно). Данные misconfigurations чрезвычайно просто и быстро находятся удаленными злоумышленниками со всего Мира с помощью сканирования портов буквально в течение нескольких минут после деплоя.
Далее идут всем хорошо известные встроенные механизмы безопасности Kubernetes. НО нужно помнить, что в каждой компании Kubernetes уникален почти как снежинка, от компании к компании разные подходы к разработке, культура/процессы работы/разработки, в конце концов разные продукты/сервисы и, конечно, же уровень зрелости в вопросах информационной безопасности.
Поэтому чужие success story о использовании того или иного инструмента или подхода могут быть совершенно не эффективны или не применимы для вас.
Инструменты/подходы должны не латать дыры, а выстраивать правильный процесс (не забываем, что безопасность — это не состояние, а процесс!) внутри компании. Так на пример использование самого крутого инструмента поиска/анализа инцидентов будет совершенно не эффективным, если команда безопасности будет утопать в этих же инцидентах, не успевая их разбирать.
Подход при котором для решение проблемы "A", возьмем решение "X", для решения проблемы "B" возьмем решение "Z" и т.д. далеко не всем по карману и в условиях быстро трансформирующегося современного бизнеса не эффективен на длинных дистанциях.
Поэтому выстраивайте процессы, а не состояния безопасности и перед тем, как что-то внедрять разбирайтесь в том что и как у вас работает/устроено внутри. Иначе внедрением почти любого security механизма можно очень легко что-то сломать … А знакомство с безопасностью должно быть приятным, а не отталкивающим =)