Что, если… забыть про безопасность кластера k8s?
Я думаю, многие слышали про громкий инцидент произошедший с Tesla в 2018 году, когда группа хакеров через консоль Kubernetes смогли получить доступ к аккаунту. После чего изрядно повеселились и настроили майнер в облачном сервисе Amazon Web Services. У многих людей сразу же возникает вопрос в голове “Как они это сделали?” и “Почему многоуважаемые ИБ данной компании не подумали о потенциальной дыре в безопасности?”. Как правило при разработке любого продукта бывают лишь две причины возникновения уязвимостей. Первая причина - человеческий фактор. Кто из нас не забывал что-либо в ходе кропотливой работы над проектом и кто не откладывал в бэклог решение “не самых срочных вопросов..?”. И, наконец, вторая причина - отсутствие необходимых компетенций в той или иной области.
Читать далееИсточник: Хабрахабр
Похожие новости
- Почему ваша LLM-платформа — следующая цель: аудит безопасности AI-сервиса изнутри
- [Перевод] Пять документов ломают ваш RAG: где реальная уязвимость и что с ней делать
- Простой гайд как на одном и том же сервере иметь и панель 3X-UI за NGINX, и свой сервис
- Спираль эволюции веб-дизайна: от десктопной версии к адаптиву и обратно к многоликости
- Окружайте, так удобнее промахиваться! Встроенные в Hugging Face проверки ML-моделей против одного сканера
- [Перевод] Проблемы санации SVG
- Яндекс Плюс AdTech: как экосистемные решения обеспечили рост продаж билетов на фильм «Горыныч»
- Молодые дизайнеры против алгоритмов: страх перед ИИ испытывает лишь каждый десятый
- Безопасность приложений на Typescript от А до Я: гайд по защите от очевидных и не очень уязвимостей
- Доля рекламных бюджетов под управлением ИИ в Яндексе достигла 85%