Безопасность несовместима с производительностью и сплоченностью команды
20 октября 2022 г.Более половины нарушений безопасности происходят внутри организации, и все же, когда мы думаем о безопасности, мы обычно думаем об уязвимостях, эксплойтах и т. д. При этом 60 % взломов происходят только от человека, который просто входит в систему и использует что, черт возьми, они хотят. Я совсем недавно думал об этом. Я потратил много времени на изучение вопросов, связанных с безопасностью, для главы моей будущей книги и, к сожалению, нашел очень мало информации об усилении защиты внутренних систем.
Да, об этом тоже есть материал. Но кажется, что подавляющее большинство ориентировано на внешние угрозы, а не на внутренние угрозы. Я понимаю. Обеспечить внутреннюю безопасность сложно, но это, вероятно, самое важное, что мы можем сделать, и, вероятно, это не так сложно, как многие из нас думают. Я хотел бы предварить это, заявив, что я не эксперт по безопасности. Причина, по которой я пишу этот пост, заключается в том, что большинство из нас не такие. Так что же мы, «обычные программисты», можем сделать, чтобы снизить риски безопасности?
Мы можем многое сделать, но большую часть этого берут на себя команды DevOps или службы безопасности. Есть также моменты о написании безопасного кода, об этом тоже много. Я хочу поговорить о некоторых вещах, которые уникальны для нашей области и не освещаются так широко. Пару десятилетий назад местная женщина украла ¼ миллиарда шекелей из местного банка (примерно 70 миллионов долларов США в то время). На это ушло время, больше десяти лет... Никто не заметил!
Как банк мог потерять 70 миллионов долларов? У них нет сдержек и противовесов? Конечно, они делают. Системы изменили эту женщину. Она была человеком, отвечающим на предупреждения системы. Она не брала выходной или отпуск, будь у нее замена, заметила бы все нарушения. Это не был технический взлом. Не в том смысле, в каком мы думаем о взломе. Но концепция та же, мы запираем двери и окна, но внутри… Это бесплатно для всех.
Эта история важна, потому что эта женщина не была плохим человеком. Мы не должны смотреть на наших коллег с подозрением. Ее шантажировала местная организованная преступность, которая и спровоцировала все это. По этой причине нам необходимо максимально ограничить воздействие и не полагаться на единственную точку отказа.
Баланс между работой и безопасностью
Внутренняя безопасность имеет много преимуществ:
- Пользователи имеют право на неприкосновенность частной жизни. Даже если наша компания не заботится об этом праве, конфиденциальность закреплена в законах и правилах по всему миру. Грубая небрежность может привести к судебным искам.
- Кража интеллектуальной собственности — это реальная проблема. Google подал в суд на Uber за кражу IP.
- В случае внешней атаки внутренняя защита значительно усложнит получение какой-либо значимой информации.
Внутренняя безопасность имеет решающее значение, и ею в основном занимаются администраторы. Как программисты, мы часто игнорируем этот конкретный аспект нашей работы. Есть несколько вещей, которые мы можем сделать в этой области. В частности: не открывайте дыры, убедитесь, что мы все регистрируем, применяем ограничения доступа и поддерживаем надежные пароли.
Чего мы не хотим, так это усложнять себе жизнь. У нас уже достаточно забот, и корпоративные политики, такие как ротация паролей, абсолютно ничего не делают для безопасности организации. Они представляют собой театр безопасности и на самом деле наносят ущерб безопасности. Пользователи пишут эти пароли на стикерах и оставляют их на своих рабочих местах. Эффективно сводит на нет их ценность.
Нам необходимо повысить безопасность, оказав минимальное влияние на повседневную работу. Это противоречивые цели, но здесь есть баланс, который мы можем найти. Нулевое доверие — это ключевое слово, используемое для большинства этих политик, это интересная тема, но я не хочу писать об этом.
Я разработчик, а не DevOps. Я тоже не специалист по безопасности. Таким образом, обязанность развертывания политики безопасности и ее защиты не лежит на мне. И не должно. Но безопасность — это командная работа. Самое слабое звено — это то, где мы все терпим неудачу. Один человек, щелкнув неверную ссылку электронной почты, может сорвать наилучшую политику безопасности. Как разработчики, мы можем многое сделать как для наших коллег, так и для клиентов, использующих наши продукты. Вот что я хочу обсудить.
Не открывайте дверь
Это может показаться безумием. Зачем нам открывать дверь? Мы заботимся о безопасности. Но мы часто открываем образную дверь, даже не задумываясь об этом. Вы оставляете удаленную отладку открытой на рабочем сервере только для проверки?
Это открытая дверь.
Даже если у вас есть правило брандмауэра. Этого недостаточно. Предполагается:
* Хакер не может обойти брандмауэр * Человек, взламывающий систему, еще не находится внутри
Оба понятия проблематичны. Теперь вы можете сказать: это нулевое доверие. Вы были бы правы на 100%. Но об этом все равно нужно сказать, поскольку многие разработчики делают подобные вещи. Так много баз данных открыто для сканирования в Интернете, что это страшно.
Если вы разработчик в команде, обратите на это внимание. Сообщите об этом и попытайтесь улучшить ситуацию. Люди часто привыкли к тому, как обстоят дела, и даже не замечают, когда прямо перед ними открывается зияющая дыра.
Использовать журналы аудита
Самое важное предположение, которое вы должны сделать как разработчик, заботящийся о безопасности, заключается в следующем: вас могут взломать. Тогда что. DevOps — это первая линия обороны. Мы, разработчики, редко делаем что-то в этом отношении. Если хакер действительно проникнет, нам придется столкнуться с двумя вещами. Во-первых, им труднее наносить урон (см. следующий раздел). Второй позже.
Что сделал хакер? Куда они делись? Что они получили? На все эти вопросы мы должны быть в состоянии ответить в случае нарушения. Нам нужна система, которая регистрирует все, но выходит за рамки регистратора. Нам нужно журналирование аудита, которое по умолчанию встроено в некоторые фреймворки и относительно легко добавляется. Благодаря этому мы можем принять меры постфактум или во время взлома и смягчить его последствия.
Говоря о логах, не переусердствуйте с логированием приложений и обязательно защитите лог. Я имел дело с несколькими организациями, где они должным образом зашифровали свою базу данных и обезопасили ее. При этом доступ к журналу был бесплатным для всех. Читая журнал, мы часто можем найти все, что нам нужно.
Токены пользователя иногда записываются непосредственно в журнал и позволяют нам выдавать себя за пользователя. Представьте себе администратора, который входит в систему. Злоумышленник, имеющий доступ к журналу, может не только выдать себя за него. Это идеальное преступление, поскольку будет казаться, что его совершил кто-то другой. Хотя мы должны просмотреть журналы и убедиться, что мы не регистрируем ничего рискованного. Мы также должны держать журнал небольшим, чтобы мы могли заметить проблемные аспекты. Кроме того, нам необходимо предоставить доступ к производственным журналам ограниченной группе людей, которым это необходимо.
Ограничения доступа
Мы должны зашифровать все, что важно. Секреты должны храниться надежно и снаружи, чтобы избежать переключения между службами для полного контроля. Источник не должен храниться с использованием тех же учетных данных или на серверах. Все должно быть доступно только для чтения и без доступа к SSH.
Если есть возможность получить доступ к рабочей среде, хакер сможет найти способ проникнуть внутрь. Отменяя обычный доступ к рабочей среде, мы устраняем эту возможность и вынуждаем хакера-злоумышленника искать нестандартный способ проникновения.
Поддерживайте хорошие пароли
Я потерпел неудачу по крайней мере в одном проекте и недостаточно оценил его ценность. Многие эксперты по безопасности клянутся менеджерами паролей. Это нормально. Но как разработчик мы должны поддерживать две вещи, когда речь заходит о паролях:
* Специальные символы * Очень длинные пароли
Некоторые проверки паролей не позволяют использовать некоторые специальные символы, что является плохим, хотя и более редким в последние годы. Но настоящая проблема заключается в длине пароля. Я люблю использовать парольные фразы. Это предложения из 5+ слов, которые имеют смысл для меня, поэтому их легко запомнить. Но невозможно угадать наугад и невозможно перебором. Например. «В 8 утра детский сад переполнен» было бы невозможно догадаться. Даже если человек стоит у меня за плечом и смотрит на меня, он не соберёт это воедино (нет, это не мой пароль). Тем не менее, некоторые системы ограничивают длину пароля до 12.
Наконец-то
Это командная работа. Да, большая часть работы выполняется командой безопасности (если она у вас есть), за которой следует DevOps. Затем есть инструменты, которые выполняют большую работу, например. защита наших зависимостей от известных уязвимостей и т. д.
Когда дело доходит до безопасности, всего этого недостаточно. Особенно, если проблема внутри компании. Мне не нравится слово «нулевое доверие», хотя технические принципы, лежащие в его основе, прочны. Я думаю, нам нужно работать в команде, чтобы обнаруживать аномалии и замечать случаи, когда все не так, как кажется. Но в основном нам нужно подготовиться к взлому. Если мы будем на 100% готовы во всех отделах. Этого никогда не случится, и это хорошо.
Нам необходимо найти тонкий баланс между бдительностью, безопасностью и производительностью. Это не простой баланс. Работать с такими инструментами, как секретные хранилища, неудобно по сравнению с простой фиксацией ключа в git или размещением файла свойств в образе. Но нам нужны такие практики по мере нашего роста. Согласен, для быстрорастущих стартапов они нам не нужны. Но, как напоминает нам твиттер. Быстрорастущие стартапы с плохими методами обеспечения безопасности становятся зрелыми публичными компаниями с плохими методами обеспечения безопасности.
:::информация Также опубликовано здесь.
:::
Оригинал