Да, если VPN на этом же сервере. В этом случае торчащий VPN немногим лучше торчащего SSH. Под VPN я имею ввиду – отдельный сервер к которому коннектится обслуживаемый сервер и обслуживающий персонал.
Совет по делегированию от IT-руководителя с 10 летним стажем. Автор, возьмите себе зама с целью воспитать себе замену. И большинство задач пропускайче через паттерн "а может ли эта задача чему-то научить моего зама?". В этом случае мотивация сменяется с "эффективно решить задачу" на "эффективно обучить зама". И барьер, о котором вы писали, рушится. Успешно проверено уже на двоих таких замах. Важно упомянуть, что зам не в смысле "прошел почти тот же путь, что и вы", а молодой, с непреодолимым желанием работать и развиваться. На "на чистый лист" ложиться лучше. Ну и не забывать себе напоминать, что роль руководителя – максимально помочь команде выполнять поставленные задачи, а не работать за троих.
В статье идет речь о максимальной качественной безопасности разработки продукта, где риски взлома оцениваются миллионами, либо необратимой потерей репутации. То есть статья для тех, кто уже отстроил безопасность на хорошем уровне и думает как его повысить. А всех, кто только начал думать об ИБ, статья может отпугнуть.
Прошу не бояться ИБ и подходить к ней по «принципу Парето», о котором отлично рассказал Алексей Лукацкий в докладе "Принцип Парето в информационной безопасности".
Принцип прост – каждый шаг, значительно снижает риски взлома. Для безопасности разрабатываемого продукта я предлагаю ТОП-3:
Как и указал автор, устранить «недостаточную инвентаризацию», т.е. просто разобраться где, что лежит, что крутиться, какие компоненты задействованы в разработке и продакшн. В процессе может выяснится, что часть серверов, где можно найти исходники ранних версий продукта, давно заброшены и подвержены взлому.
Инвентаризация административных доступов и проверка репозиториев на предмет сохраненных ключей.
Сканирование любыми доступными вам сканерами уже отсекут львиную долю низкоквалифицированных злоумышленников, а вам даст уверенность, что у вас нет зияющих дыр и грубых ошибок конфигурирования.
Это уже значительно (с «нуля» до «сносно») повысит уровень защищенности вашего приложения. Но этого не достаточно, чтобы остановить квалифицированного хакера, которого наймет конкурент за $3-5k. Для повышения этой планки необходимо внедрять процессы описанные автором.
Предположу обратное. Похоже на конец этапа «пика чрезмерных ожиданий» и переход в этап «избавление от иллюзий» по циклу хайпа Garter.
каждый раз в выборку могут попадать чуть разные компании
Значит и в прошлые опросы тоже попадали чуть разные компании, следовательно, считаем выборку репрезентативной.
опрашивались не пользователи Docker
В оригинале, к сожалению, не нашел деталей опроса. Предположу, что опросы были на ресурсах связанных CNCF. Следовательно, опросили только тех, кто использует стек CNCF, который развивается в основном вокруг docker.
Никто не боится облаков, никакой паники, никто не отрицает, что облака удобнее. Просто компетентные люди не хотят принимать неизвестные риски. Вместо того, чтобы уговаривать довериться вам, лучше дайте больше оснований считать, что ваше облако безопасно: какие данные вам видны, как долго храните, кто их видит, какие возможности есть у вас вмешиваться в процессы, как вы защищаетесь от человеческого фактора?
Двухфакторная авторизация и сложный пароль вполне надежно защитят данные в облаке.
Это надёжно защищает от кражи пароля, но никак не характеризует безопасность вашего облака.
Риск раскрытия хранящейся в облаке информации и цена последствий несравнимы с удобством облачного хранения документов и коллективной работы.
Сравнивание "теплого с мягким". Если перефразировать: "мы не можем сделать удобное self-hosted решение, поэтому сделали как нам удобно, но просим вас поступиться приватностью".
uMatrix-плагин для браузера позволяет гибко и удобно отключать загрузку произвольных ресурсов на сайте, без необходимости отключать js целиком. Рекомендую!
В любом случае придется кому-то довериться. Вы доверяете Apple/Google пользуясь их телефонами, вы доверяете антивирусу, хотя он знает о том как поломать ваш комп и незаметно получить все ваши данные. Использование опенсурс минимизирует зависимость от вендоров, т.к. потенциально можно код посмотреть и не сильно при этом доверять разработчикам. Т.е. чем меньше проприетарного ПО, тем меньше компаний, которым необходимо доверять. В случае all-in-one мы должны доверять только сборщику. Мы верим, что canonical собирая убунту не делает закладок. Я верю Cloudron, что он не сливает мои данные. Ну гуглу нам приходится не просто верить, что закладок нет, нам приходится отдавать им данные и надеяться, что он аккуратно с ними обращается.
Тем, что все твои данные остаются на твоём сервере. Да, мы не можем быть на 100% уверены, что Cloudron не сливает себе что-то. Тем более мы не можем быть уверены в админе. Но про гугл мы знаем точно – все наши данные у них.
Идеальная альтернатива гугл-сераисам – это все самому собрать, желательно из исходников, и самому сопровождать (обновлять, мониторить). Плохое сопровождение (поставил и забыл) нивелирует плюсы от своей независимой инфраструктуры, т.к. она устаревает и становится небезопасной. Поэтому, если мы не хотим тратить свое время, надо кого-то нанять для сопровождения. Отдельного человека дорого и тоже не особо безопасно, лучше обратиться к какой-то массовой отлаженной и автоматизированной услуге. Так вот, ребята из Cloudron упаковали достойные опенсурс продукты в docker, настроили CI/CD и предложили клиенту установить все это на его сервер. Фактически, это замена отдельного админа за $15 в месяц. Это не opensource продукт, это услуга. Да, отсутвие прозрачности добавляет некоторые риски, но меньшие чем привносит наемный админ.
PTR, да, надо прописать, но SFP и DKIM Cloudron сам гененерит. Забыл упомянуть, что Cloudron сам заботятся об обновлении установленных сервисах. Своеобразный DevOps as Service. Фактически, админ не нужен. Из недостатков – нет простого способа собрать логи со всех сервисов для контроля доступа. Но разработчики отзывчивые, обещали сделать.
Странно, но вполне здраво, что при выборе решения у нас на первом месте не цена, а доверие производителю.
Боюсь, что это не признак успеха. Гораздо эффективнее доверять развитым государственным институтам и законам, чем выстраивать доверительные отношения с каждым из контрагентов.
Доверительные отношения — это не плохо. Но работать хочется с большим количеством партнёров, чем только с теми с кем успеваешь выстроить хорошие доверительные отношения.
Спасибо за отзывчивость avagin, я ей воспользуюсь. Я искренне считаю, что контейнеризация еще не раскрыла свой потенциал. Docker не для персистентных хостов, а для других задач, а вот LXC/LXD/VZ — то что надо. У нас уже больше года в проде крутится ~500 LXC-контейнеров и ожидается троекратный рост. Все прекрасно, кроме вот миграции живой.
Последовав совету, создали баг-репорт в LXC, но его оперативно закрыли и направили к вам. А мы пришли — баг-репорт в CRIU. Помогите, пожалуйста.
Да, если VPN на этом же сервере. В этом случае торчащий VPN немногим лучше торчащего SSH. Под VPN я имею ввиду – отдельный сервер к которому коннектится обслуживаемый сервер и обслуживающий персонал.
Это относительно архитектуры, когда сервер доступен только для CDN. То есть в white-list'е только ip CDN'a.
Да, VPN однозначно лучше white-list, т.к. добавляет шифрование. Но если нет возможности поднять VPN, то white-list гораздо лучше, чем ничего.
Совет по делегированию от IT-руководителя с 10 летним стажем. Автор, возьмите себе зама с целью воспитать себе замену. И большинство задач пропускайче через паттерн "а может ли эта задача чему-то научить моего зама?". В этом случае мотивация сменяется с "эффективно решить задачу" на "эффективно обучить зама". И барьер, о котором вы писали, рушится. Успешно проверено уже на двоих таких замах. Важно упомянуть, что зам не в смысле "прошел почти тот же путь, что и вы", а молодой, с непреодолимым желанием работать и развиваться. На "на чистый лист" ложиться лучше. Ну и не забывать себе напоминать, что роль руководителя – максимально помочь команде выполнять поставленные задачи, а не работать за троих.
В статье идет речь о максимальной качественной безопасности разработки продукта, где риски взлома оцениваются миллионами, либо необратимой потерей репутации. То есть статья для тех, кто уже отстроил безопасность на хорошем уровне и думает как его повысить. А всех, кто только начал думать об ИБ, статья может отпугнуть.
Прошу не бояться ИБ и подходить к ней по «принципу Парето», о котором отлично рассказал Алексей Лукацкий в докладе "Принцип Парето в информационной безопасности".
Принцип прост – каждый шаг, значительно снижает риски взлома. Для безопасности разрабатываемого продукта я предлагаю ТОП-3:
Это уже значительно (с «нуля» до «сносно») повысит уровень защищенности вашего приложения. Но этого не достаточно, чтобы остановить квалифицированного хакера, которого наймет конкурент за $3-5k. Для повышения этой планки необходимо внедрять процессы описанные автором.
А как из консоли проверить?
Значит и в прошлые опросы тоже попадали чуть разные компании, следовательно, считаем выборку репрезентативной.
В оригинале, к сожалению, не нашел деталей опроса. Предположу, что опросы были на ресурсах связанных CNCF. Следовательно, опросили только тех, кто использует стек CNCF, который развивается в основном вокруг docker.
Никто не боится облаков, никакой паники, никто не отрицает, что облака удобнее. Просто компетентные люди не хотят принимать неизвестные риски. Вместо того, чтобы уговаривать довериться вам, лучше дайте больше оснований считать, что ваше облако безопасно: какие данные вам видны, как долго храните, кто их видит, какие возможности есть у вас вмешиваться в процессы, как вы защищаетесь от человеческого фактора?
Это надёжно защищает от кражи пароля, но никак не характеризует безопасность вашего облака.
Сравнивание "теплого с мягким". Если перефразировать: "мы не можем сделать удобное self-hosted решение, поэтому сделали как нам удобно, но просим вас поступиться приватностью".
uMatrix-плагин для браузера позволяет гибко и удобно отключать загрузку произвольных ресурсов на сайте, без необходимости отключать js целиком. Рекомендую!
В любом случае придется кому-то довериться. Вы доверяете Apple/Google пользуясь их телефонами, вы доверяете антивирусу, хотя он знает о том как поломать ваш комп и незаметно получить все ваши данные. Использование опенсурс минимизирует зависимость от вендоров, т.к. потенциально можно код посмотреть и не сильно при этом доверять разработчикам. Т.е. чем меньше проприетарного ПО, тем меньше компаний, которым необходимо доверять. В случае all-in-one мы должны доверять только сборщику. Мы верим, что canonical собирая убунту не делает закладок. Я верю Cloudron, что он не сливает мои данные. Ну гуглу нам приходится не просто верить, что закладок нет, нам приходится отдавать им данные и надеяться, что он аккуратно с ними обращается.
Тем, что все твои данные остаются на твоём сервере. Да, мы не можем быть на 100% уверены, что Cloudron не сливает себе что-то. Тем более мы не можем быть уверены в админе. Но про гугл мы знаем точно – все наши данные у них.
Идеальная альтернатива гугл-сераисам – это все самому собрать, желательно из исходников, и самому сопровождать (обновлять, мониторить). Плохое сопровождение (поставил и забыл) нивелирует плюсы от своей независимой инфраструктуры, т.к. она устаревает и становится небезопасной. Поэтому, если мы не хотим тратить свое время, надо кого-то нанять для сопровождения. Отдельного человека дорого и тоже не особо безопасно, лучше обратиться к какой-то массовой отлаженной и автоматизированной услуге. Так вот, ребята из Cloudron упаковали достойные опенсурс продукты в docker, настроили CI/CD и предложили клиенту установить все это на его сервер. Фактически, это замена отдельного админа за $15 в месяц. Это не opensource продукт, это услуга. Да, отсутвие прозрачности добавляет некоторые риски, но меньшие чем привносит наемный админ.
PTR, да, надо прописать, но SFP и DKIM Cloudron сам гененерит. Забыл упомянуть, что Cloudron сам заботятся об обновлении установленных сервисах. Своеобразный DevOps as Service. Фактически, админ не нужен. Из недостатков – нет простого способа собрать логи со всех сервисов для контроля доступа. Но разработчики отзывчивые, обещали сделать.
Для личных нужд рекомендую стек: scaleway – дешёвый bare-metal хостинг + clodrone –удобно упакованный opensource (email, rocket chat, OpenVPN, gitlab и т.п) автоматически правит субдомены, генерит let's encrypt сертификат, бэкапит в s3, централизованное управление юзерами. Не реклама – делюсь опытом.
Боюсь, что это не признак успеха. Гораздо эффективнее доверять развитым государственным институтам и законам, чем выстраивать доверительные отношения с каждым из контрагентов.
Доверительные отношения — это не плохо. Но работать хочется с большим количеством партнёров, чем только с теми с кем успеваешь выстроить хорошие доверительные отношения.
Последовав совету, создали баг-репорт в LXC, но его оперативно закрыли и направили к вам. А мы пришли — баг-репорт в CRIU. Помогите, пожалуйста.