60% нарушений безопасности происходят внутри организации, и все же, когда мы думаем о безопасности, мы обычно думаем об уязвимостях, эксплойтах и ​​т. д. В то же время 60% взломов происходят только от человека, который просто входит в систему и берет что угодно. они хотят. Я совсем недавно думал об этом. Я потратил много времени на изучение вопросов, связанных с безопасностью, для главы моей будущей книги и, к сожалению, нашел очень мало информации об укреплении внутренних систем.

Да, об этом тоже есть материал. Но кажется, что подавляющее большинство ориентировано на внешние угрозы, а не на внутренние угрозы. Я понимаю. Обеспечить внутреннюю безопасность сложно, но это, вероятно, самое важное, что мы можем сделать, и, вероятно, это не так сложно, как многие из нас думают. Я хотел бы предварить это, заявив, что я не эксперт по безопасности. Причина, по которой я пишу этот пост, заключается в том, что большинство из нас не такие. Так что же мы, «обычные программисты», можем сделать, чтобы снизить риски безопасности?

Мы можем многое сделать, но большую часть этого берут на себя команды DevOps или службы безопасности. Есть также моменты о написании безопасного кода, об этом тоже много. Я хочу поговорить о некоторых вещах, которые уникальны для нашей области и не освещаются так широко. Пару десятилетий назад местная женщина украла ¼ миллиарда шекелей из местного банка (примерно 70 миллионов долларов США в то время). На это ушло время, больше десяти лет… Никто не заметил!

Как банк мог потерять 70 миллионов долларов? У них нет сдержек и противовесов? Конечно, они делают. Системы изменили эту женщину. Она была человеком, отвечающим на предупреждения системы. Она не брала выходной или отпуск, будь у нее замена, заметила бы все нарушения. Это не был технический взлом. Не в том смысле, в каком мы думаем о взломе. Но концепция та же, мы запираем двери и окна, но внутри… Бесплатно для всех.

Эта история важна, потому что эта женщина не была плохим человеком. Мы не должны смотреть на наших коллег с подозрением. Ее шантажировала местная организованная преступность, которая и спровоцировала все это. Из-за этого нам нужно максимально ограничить наше воздействие и избегать полагаться на единственную точку отказа.

Баланс работы/безопасности

Внутренняя безопасность имеет много преимуществ:

  • Пользователи имеют право на неприкосновенность частной жизни. Даже если наша компания не заботится об этом праве, конфиденциальность закреплена в законах и правилах по всему миру. Грубая небрежность может привести к судебным искам.
  • Кража IP является реальной проблемой, например. Google подал в суд на Uber за кражу IP.
  • В случае внешней атаки внутренние средства защиты значительно усложнят получение какой-либо значимой информации.

Внутренняя безопасность имеет решающее значение и в основном осуществляется администраторами. Как программисты, мы часто игнорируем этот конкретный аспект нашей работы. Есть несколько вещей, которые мы можем сделать в этой области. В частности: не открывайте дыры, убедитесь, что мы все регистрируем, применяем ограничения доступа и поддерживаем хорошие пароли.

Чего мы не хотим, так это усложнять себе жизнь. У нас уже достаточно забот, и корпоративные политики, такие как ротация паролей, абсолютно ничего не делают для безопасности организации. Они представляют собой театр безопасности и на самом деле наносят ущерб безопасности. Пользователи пишут эти пароли на стикерах и оставляют их на своих рабочих местах. Эффективно сводит на нет их ценность.

Нам необходимо повысить безопасность, оказав минимальное влияние на повседневную работу. Это противоречивые цели, но здесь есть баланс, который мы можем найти. Нулевое доверие — это ключевое слово, используемое для большинства этих политик, это интересная тема, но я не хочу писать об этом.

Я разработчик, а не DevOps. Я тоже не специалист по безопасности. Таким образом, обязанность развертывания политики безопасности и ее защиты не лежит на мне. И не должно. Но безопасность — это командная работа. Самое слабое звено — это то, где мы все терпим неудачу. Один человек, щелкнув неверную ссылку электронной почты, может сорвать наилучшую политику безопасности. Как разработчики, мы можем многое сделать как для наших коллег, так и для клиентов, использующих наши продукты. Это то, что я хочу обсудить.

Не открывай дверь

Это может показаться безумием. Зачем нам открывать дверь? Мы заботимся о безопасности. Но мы часто открываем образную дверь, даже не задумываясь об этом. Вы оставляете удаленную отладку открытой на рабочем сервере только для проверки?

Это открытая дверь.

Даже если у вас есть правило брандмауэра. Этого недостаточно. Предполагается:

  • Хакер не может обойти брандмауэр
  • Человек, взламывающий систему, еще не внутри

Оба понятия проблематичны. Теперь вы можете сказать: это нулевое доверие. Вы были бы правы на 100%. Но об этом все равно нужно сказать, поскольку многие разработчики делают подобные вещи. Столько баз данных открыто для сканирования в интернете, это страшно.

Если вы разработчик в команде, обратите на это внимание. Сообщите об этом и попытайтесь улучшить ситуацию. Люди часто привыкли к тому, как обстоят дела, и даже не замечают, когда прямо перед ними открывается зияющая дыра.

Используйте журналы аудита

Самое важное предположение, которое вы должны сделать как разработчик, заботящийся о безопасности, заключается в следующем: вас могут взломать. И что. DevOps — это первая линия обороны. Мы, разработчики, редко делаем что-то в этом отношении. Если хакер действительно проникнет, нам придется столкнуться с двумя вещами. Во-первых, им труднее наносить урон (см. следующий раздел). Второй позже.

Что сделал хакер? Куда они делись? Что они получили? На все эти вопросы мы должны быть в состоянии ответить в случае нарушения. Нам нужна система, которая регистрирует все, но выходит за рамки регистратора. Нам нужно журналирование аудита, которое по умолчанию встроено в некоторые фреймворки и относительно легко добавляется. При этом мы можем следить постфактум или во время взлома и смягчить его.

Говоря о логах, не переусердствуйте с логированием приложений и обязательно защитите лог. Я имел дело с несколькими организациями, где они должным образом зашифровали свою базу данных и обезопасили ее. При этом доступ к журналу был бесплатным для всех. Читая журнал, мы часто можем найти все, что нам нужно. Токены пользователя иногда записываются непосредственно в журнал и позволяют нам выдавать себя за пользователя. Представьте себе администратора, который входит в систему. Злоумышленник, имеющий доступ к журналу, может не только выдать себя за него. Это идеальное преступление, поскольку будет казаться, что его совершил кто-то другой. Хотя мы должны просмотреть журналы и убедиться, что мы не регистрируем ничего рискованного. Мы также должны держать журнал небольшим, чтобы мы могли заметить проблемные аспекты. Кроме того, нам нужно ограничить доступ к производственным журналам для ограниченной группы людей, которым необходимо знать.

Ограничения доступа

Мы должны зашифровать все, что важно. Секреты должны храниться надежно и снаружи, чтобы избежать переключения между службами для полного контроля. Источник не должен храниться с использованием тех же учетных данных или на серверах. Все должно быть доступно только для чтения и без SSH-доступа.

Если есть доступ к продакшену, хакер может найти путь внутрь. Убрав обычный доступ к продакшену, мы убираем эту возможность и вынуждаем злонамеренного хакера искать нестандартный путь внутрь.

Поддержите хорошие пароли

Я потерпел неудачу в этом по крайней мере в одном проекте и недостаточно оценил ценность этого. Многие эксперты по безопасности клянутся менеджерами паролей. Это нормально. Но как разработчик мы должны поддерживать две вещи, когда речь идет о паролях:

  • Специальные символы
  • Очень длинные пароли

Некоторая проверка пароля не позволяет использовать некоторые специальные символы, что просто плохо, хотя и реже в последние годы. Но настоящая проблема заключается в длине пароля. Я люблю использовать парольные фразы. Это предложения из 5+ слов, которые имеют смысл для меня, поэтому их легко запомнить. Но невозможно угадать наугад и невозможно перебором. Например. «В 8 утра детский сад переполнен» было бы невозможно догадаться. Даже если человек стоит у меня за плечом и смотрит на меня, он не соберёт это воедино (нет, это не мой пароль). Тем не менее, некоторые системы ограничивают длину пароля до 12.

Окончательно

Это командная работа. Да, большая часть работы выполняется командой безопасности (если она у вас есть), за которой следует DevOps. Затем есть инструменты, которые выполняют большую работу, например. поддержание наших зависимостей в чистоте от известных уязвимостей и т. д.

Когда дело доходит до безопасности, всего этого недостаточно. Особенно, если проблема внутри компании. Мне не нравится слово «нулевое доверие», хотя технические принципы, лежащие в его основе, прочны. Я думаю, нам нужно работать в команде, чтобы обнаруживать аномалии и замечать случаи, когда все не так, как кажется. Но в основном нам нужно подготовиться к взлому. Если мы будем на 100% готовы во всех отделах. Он никогда не придет, и это хорошо.

Нам необходимо найти тонкий баланс между бдительностью, безопасностью и производительностью. Это не простой баланс. Работать с такими инструментами, как секретные хранилища, неудобно по сравнению с простой фиксацией ключа в git или размещением файла свойств в образе. Но нам нужны такие практики по мере нашего роста. Согласен, для быстрорастущих стартапов они нам не нужны. Но, как напоминает нам твиттер. Быстрорастущие стартапы с плохими методами безопасности становятся зрелыми публичными компаниями с плохими методами безопасности.