Что может включаться в чек лист application security
OWASP TOP-10: практический взгляд на безопасность веб-приложений
Хабр, привет! Мы — Иван Притула и Дмитрий Агапитов, занимаемся разработкой решений, которые делают жизнь людей проще и комфортнее. Сегодня мы хотим представить один из наших новых сервисов – это платежный агрегатор SimplePay. Все что мы делаем продиктовано мучительной невозможностью мириться с несовершенством в целом, и несовершенством конкретных программных решений в частности. Именно в погоне за совершенством и рождаются наши продукты. Стараемся мы изо всех сил, а уж насколько мы близки, судить не нам.
Чтобы Всем было интереснее, мы не будем рекламировать свой сервис (ну если только чуть-чуть). Вместо этого, мы подготовили первую серию публикаций, которая будет посвящена такой увлекательной и крайне актуальной теме, как безопасность Web-приложений. Мы постараемся раскрыть опасности, сопутствующие любому действующему интернет-проекту и простым языком донести всю важность ответственного подхода к рутинным, казалось бы, мелочам в вопросах безопасности данных. Надеемся наши статьи будут не бесполезны для Вас. Уверены, так Вы узнаете нас гораздо лучше.
SimplePay — это современный высокотехнологичный агрегатор платежей. Компания создана в 2014г., зарегистрирована в г. Москве и ведет свою деятельность в соответствии с законодательством Российской Федерации. Наша основная задача, это обеспечение простой, удобной возможности организации приема платежей на интернет-сайтах компаний, вне зависимости от сферы деятельности, масштаба бизнеса и наличия подготовленного технического персонала.
Мы предлагаем следующие услуги:
Безопасность веб-приложений
Современный мир несет в себе тысячи угроз и потенциальных опасностей буквально на каждом шагу и в каждый момент времени. Всемирная сеть, ставшая неотъемлемой частью нашей жизни, не является исключением.
Киберпреступность сейчас развита как никогда – ведь почти каждая компания имеет свой сайт в интернете, а злоумышленник в сети может легко оставаться абсолютно анонимным.
При этом все компании, имеющие сайт в интернете, делятся на три типа:
Акцент на возможности практического применения сделан не случайно. Мы считаем, что недостаточно знать теорию для понимания истинного масштаба угрозы – ведь уязвимости, которые выглядят не очень страшно в теории, зачастую могут нести катастрофические для бизнеса последствия.
Количество угроз растет пропорционально росту бизнеса, однако как показала многолетняя практика, 99% атак происходят через десяток стандартных ошибок валидации входящих данных, либо обнаруженные уязвимости в установленных компонентах программного обеспечения сторонних производителей, либо банально, по халатности системных администраторов, использующих настройки и пароли, установленные по-умолчанию.
Классификацией векторов атак и уязвимостей занимается сообщество OWASP (Open Web Application Security Project). Это международная некоммерческая организация, сосредоточенная на анализе и улучшении безопасности программного обеспечения.
OWASP создал список из 10-и самых опасных векторов атак на Web-приложения, этот список получил название OWASP TOP-10 и в нем сосредоточены самые опасные уязвимости, которые могут стоить некоторым людям больших денег, или подрыва деловой репутации, вплоть до потери бизнеса.
В этой вводной статье мы пробежимся по списку OWASP TOP-10, а далее в рамках серии наших статей «Теория и практика защиты Web-приложений» подробно рассмотрим каждый из перечисленных векторов атак, методы практической эксплуатации, степень опасности на примерах реального бизнеса, а также методы практической защиты Web-приложений и Web-сервисов.
Мы постараемся вести изложение максимально доступно, с целью донести информацию не только и не столько до технических специалистов, но также до собственников и управляющих бизнеса, которые, порой, пребывают в счастливом неведении, пока их не сломали злоумышленники, и занимаются онлайн-бизнесом, не ведая о серьезнейшей опасности, нависшей над ними.
1. Инъекции — Injections
Все данные, как правило, хранятся в специальных базах, обращения к которым строятся в виде запросов, чаще всего написанных на специальном языке запросов SQL (Structured Query Language – структурированный язык запросов).
Приложения используют SQL-запросы для того, чтобы получать, добавлять, изменять или удалять данные, например при редактировании пользователем своих личных данных или заполнении анкеты на сайте. При недостаточной проверке данных от пользователя, злоумышленник может внедрить в форму Web-интерфейса приложения специальный код, содержащий кусок SQL-запроса.
Такой вид атаки называется инъекция, в данном случае самый распространённый — SQL-инъекция. Это опаснейшая уязвимость, позволяющая злоумышленнику получить доступ к базе данных и возможность читать/изменять/удалять информацию, которая для него не предназначена.
Например, изменить вместе с именем и фамилией баланс своего счета, посмотреть баланс чужого счета, или же, похитить конфиденциальные личные данные.
Эта уязвимость является следствием недостаточной проверки данных, поступающих от пользователя. Это позволяет злоумышленнику «подсунуть», например, в веб-формы, специально подготовленные запросы, которые «обманут» приложение и позволят прочитать или записать нелегитимные данные.
В целом эта разновидность атак имеет общее название «Ошибки валидации», к ней относятся далеко не только SQL-инъекции и мы будем упоминать этот вектор еще не раз.
2. Недочеты системы аутентификации и хранения сессий (Broken Authentication and Session Management)
Для того, чтобы отличать одного пользователя от другого, web-приложение использует так называемые сессионные куки. После того, как Вы ввели логин и пароль и приложение вас авторизовало, в хранилище браузера сохраняется специальный идентификатор, который браузер в дальнейшем предъявляет серверу при каждом запросе страницы вашего web-приложения. Именно так web-приложение понимает, что Вы это именно Вы.
В случае, если ваш идентификатор украдет злоумышленник, а в системе не были реализованы проверки, скажем IP-адреса сессии, или проверки наличия более одного соединения в одной сессии, злоумышленник сможет получить доступ в систему с правами вашего аккаунта. А если это интернет-банк или кабинет платежной системы, о последствиях такого несанкционированного доступа Вы можете легко догадаться сами.
3. Межсайтовый скриптинг – XSS (Cross Site Scripting)
Межсайтовый скриптинг – еще одна ошибка валидации пользовательских данных, которая позволяет передать JavaScript код на исполнение в браузер пользователя. Атаки такого рода часто также называют HTML-инъекциями, ведь механизм их внедрения очень схож с SQL-инъекциями, но в отличие от последних, внедряемый код исполняется в браузере пользователя. Чем это чревато?
Во-первых, злоумышленник может украсть вашу сессионную cookie, последствия чего были описаны во втором пункте, буквально парой абзацев выше. Нужно отметить, что далеко не все серверы приложений уязвимы к данному типу атак, об этом мы отдельно поговорим в пункте под номером 5.
Во-вторых, могут быть украдены данные, вводимые в формы на зараженной странице. А это могут быть конфиденциальные персональные данные, или, что еще хуже, данные кредитной карты вместе с CVC-кодом.
В третьих, через JavaScript можно изменять данные, расположенные на странице, например, там могут быть реквизиты для банковского перевода, которые злоумышленник с удовольствием подделает и заменит подставными.
4. Небезопасные прямые ссылки на объекты (Insecure Direct Object References)
Данный вид уязвимости является также следствием недостаточной проверки пользовательских данных. Суть ее заключается в том, что при выводе каких-либо конфиденциальных данных, например личных сообщений или учетных карточек клиентов, для доступа к объекту используется идентификатор, который передается в открытом виде в адресной строке браузера, И не реализована проверка прав доступа к объектам. Например, есть страница, которая отображает личное сообщение и она имеет адрес вида:
Перебирая число после «id=» можно будет читать чужие личные сообщения. Эксплуатация данной уязвимости очень проста и не требует вообще никаких специальных навыков – достаточно лишь перебирать число в адресной строке браузера и наслаждаться результатом. Как ни парадоксально, но этой детской болезни, порой были подвержены достаточно крупные европейские платежные системы.
5. Небезопасная конфигурация (Security Misconfiguration)
Безопасность Web-приложения требует наличия безопасной конфигурации всех компонентов инфраструктуры: компонентов приложения (таких как фреймворки – frameworks), веб-сервера, сервера баз данных и самой платформы. Настройки компонентов сервера по-умолчанию зачастую небезопасны и открывают возможности к атакам. Например, кража сессионной cookie через JavaScript при XSS-атаке становится возможна благодаря выключенной по-умолчанию настройке cookie_http only.
При правильной настройке сервера и включенной опции cookie_httponly, получить сессионную cookie через JavaScript невозможно, но зачастую эта простая и важная настройка отсутствовала в таких критично важных местах, как личные кабинеты платежных систем.
Еще один пример детской уязвимости – использование настроек по-умолчанию в серверах баз данных, таких как Redis, Memcached и других – закрытая служба может быть доступна на публичном IP-адресе сервера, и/или использовались пароли, установленные производителем по-умолчанию. Это позволяет злоумышленнику запросто читать и изменять данные, в числе которых, нередко бывают и сессионные cookies (чем это чревато – мы уже знаем) и выводимые пользователям в браузер данные (что позволяет еще и XSS-атаку применить).
Кроме того, программное обеспечение должно быть в актуальном состоянии: уязвимости находят каждый день в самых различных программных компонентах – операционной системе, web-серверах, серверах баз данных, почтовых серверах и т.д. И даже если ваше приложение правильно написано и тщательно проверяет все входящие данные, и вообще, хорошо защищено, это не означает что в один прекрасный момент не найдется уязвимость в вашей ОС или Web-сервере.
6. Незащищенность критичных данных (Sensitive Data Exposure)
Многие веб-приложения не защищают конфиденциальные данные, такие как кредитные карты и учетные данные для аутентификации. Злоумышленники могут украсть или модифицировать такие слабо защищенные данные для использования в своих корыстных целях.
Самый простой пример – передача данных по протоколу HTTP. Дело в том, что данные передаваемые по протоколу HTTP никак не шифруются, а при прохождении данных от компьютера пользователя до Web-сервера, данные пройдут достаточно много различных узлов: маршрутизатор офиса или домашний роутер, маршрутизатор провайдера, маршрутизатор на канале, маршрутизатор в дата-центре хостинг-провайдера сервера и так далее. На каждом из этих узлов может затаиться зловред, так называемый сниффер, программа, которая считывает весь трафик и передает злоумышленнику. А последний просматривает полученные данные на предмет персональных данных и данных кредитных карт.
Такие данные должны передаваться исключительно по протоколу HTTPS, о чем должна гласить соответствующая надпись в адресной строке браузера:
Еще одна задача SSL-сертификата (а именно так называется специальный ключ, при помощи которого осуществляется проверка подлинности и шифрование в HTTPS) – подтвердить, что он выдан именно для данного сайта. В случае, если сертификат просрочен или подделан, Вы увидите следующую картину:
Другой пример – отсутствие шифрования критичных данных, таких как пароли или номера кредитных карт. В случае, если данные зашифрованы, то даже в случае получения несанкционированного доступа на сервер, злоумышленник не сможет украсть критичные данные. К паролям, в частности, должна применяться необратимая хеш-функция – расшифровать шифрограмму при этом не возможно и проверка пароля происходит путем формирования шифрограммы введенного пароля и сравнения ее с имеющейся в базе.
7. Отсутствие функций контроля доступа (Missing Function Level Access Control)
Суть уязвимости, как следует из названия, заключается в отсутствии проверки наличия надлежащего доступа к запрашиваемому объекту.
Большинство веб-приложений проверяют права доступа, прежде чем отобразить данные в пользовательском интерфейсе. Тем не менее, приложения должны выполнять те же проверки контроля доступа на сервере при запросе любой функции. Ведь есть еще множество вспомогательных служебных запросов, которые, зачастую отправляются в фоновом режиме асинхронно, при помощи технологии AJAX.
Если параметры запроса не достаточно тщательно проверяются, злоумышленники смогут подделать запрос для доступа к данным без надлежащего разрешения.
Частный, и пожалуй, самый распространенный случай данной уязвимости мы уже рассмотрели в 4 пункте нашей статьи – отсутствие проверки пользователя в личных сообщениях.
8. Межсайтовая подделка запроса (Cross-Site Request Forgery, CSRF/XSRF)
Вектор атаки CSRF, также известный как XSRF, позволяет злоумышленнику выполнять от имени жертвы действия на сервере, где не реализованы дополнительные проверки.
Например, в некоторой платежной системе для перевода средств на другой аккаунт, есть страница вида:
demobank.com/transfer_money.jsp?transfer_amount=1000&transfer_account=123456789
где transfer_amount – сумма для перевода и transfer_account – номер аккаунта, куда должны быть переведены средства.
Если жертва заходит на сайт, созданный злоумышленником, от её лица тайно отправляется запрос на вышеуказанную страницу платежной системы. Как результат – деньги уйдут на счет злоумышленника, после чего, вероятно, будут оперативно обменяны на Bitcoin или переведены в другую безвозвратную платежную систему, и получить их назад уже не получится.
Предполагается, что жертва должна была предварительно пройти аутентификацию в платежной системе и должна быть открыта активная сессия (скажем, страница платежной системы открыта в другой вкладке браузера).
Решается проблема достаточно просто и об этом мы расскажем в отдельной статье, посвященной CSRF.
9. Использование компонентов с известными уязвимостями (Using Components with Known Vulnerabilities)
Зачастую web-приложения написаны с использованием специальных библиотек или «фреймворков» (англ – framework), которые поставляются сторонними компаниями. В большинстве случаев эти компоненты имеют открытый исходный код, а это означает, что они есть не только у вас, но и у миллионов людей во всем мире, которые штудируют их исходный код, в том числе, и на предмет уязвимостей. И нужно отметить, что делают они это отнюдь не безуспешно.
Также уязвимости ищут (и находят) в более низкоуровневых компонентах системы, таких как сервер базы данных, web-сервер, и наконец, компоненты операционной системы вплоть до ее ядра.
Очень важно использовать последние версии компонентов и следить за появляющимися известными уязвимостями на сайтах типа securityfocus.com.
10. Непроверенные переадресации и пересылки (Unvalidated Redirects and Forwards)
Web-приложения зачастую переадресуют пользователя с одной страницы на другую. В процессе могут использоваться ненадлежащим образом проверяемые параметры с указанием страницы конечного назначения переадресации.
Без соответствующих проверок, атакующий может использовать такие страницы для переадресации жертвы на подложный сайт, который, к примеру, может иметь очень схожий или неотличимый интерфейс, но украдет ваши данные кредитной карты или другие критичные конфиденциальные данные.
Этот вид уязвимостей, также как и многие другие перечисленные выше, является разновидностью ошибок проверки входящих данных (input validation).
Вместо заключения
Мы рассмотрели основные виды уязвимостей из OWASP TOP-10 в общем виде, постарались рассказать о них максимально простым языком, а также показать на простых практических примерах, какие риски несут для вашего бизнеса те или иные векторы атак.
В первую очередь эта статья была рассчитана на собственников интернет-проектов и молодых разработчиков. В дальнейших статьях мы осветим более подробно каждый из упомянутых векторов атак, уже с развернутыми техническими подробностями и наглядными примерами, и конечно же, способами защиты.
Если Вы – собственник бизнеса, мы надеемся, что ваше понимание рисков, связанных с IT-безопасностью стало более полным, а следующие статьи могут стать отличным пособием для ваших IT-специалистов.
Application Security Training
Application Security Training Redefined.
Accelerating Application Security Training and Software Security Education through Interactive Learning
Who We Are
Kontra is built by industry veterans who invented and pioneered the first interactive application security training platform.
What Makes us Different
We don’t offer secure coding quizzes, that are effectively re-skinned multiple-choice questions.
If that’s your idea of educating developers about software security, we are not the company for you.
Developers are who we serve. Adding artificial metrics, meaningless rewards and silly badges is not what we do.
We respect their time far too much to patronize them with these gimmicks.
The days of heavily scripted OWASP Top 10 training videos with robotic voice-overs are over.
Interactive storytelling with realness and purpose in short bursts is what put’s developers in the middle of the action and drives a truly engaging learning experience.
Ludic Fallacy i.e. the misuse of games to model real-life situations is how we think of training labs.
Developers are more engaged in training if the content has a basis in reality rather than contrived examples.
KONTRA
Developer First Application Security Training
Built For Developers, By Developers
Simply Beautiful
We set out to design the most beautiful application security training experience ever built. Backed by the same team that invented the first-ever interactive application security training platform for enterprise developers, we repeatedly pored over every pixel and design element to create a visually stunning and engaging learning experience.
Every minute detail, whether it be a simple tooltip to annotate vulnerable code blocks, or a complex user interface layout has been meticulously crafted from the ground up and relentlessly refined.
Interactive Learning
Learn software security issues visually by tracing a vulnerability from the UI to its source.
Interact with vulnerable components and business logic of real-world examples.
Think like a hacker, analyzing attack surfaces in your applications and recreating their steps.
Understand and apply security code fixes to remediate vulnerabilities.
Integrate with leading Learning Management Systems
Kontra’s SCORM compliant content works out-of-the-box with leading third-party learning management systems and enterprise training platforms to enable faster integration and deployment.
The key providers include WorkDay, Skillsoft, SAP Success Factors, SAP Litmos, Saba Cloud, Oracle PeopleSoft, Looop, Docebo, Cornerstone Learning, Adobe Captivate, Absorb LMS, 360Learning, Rise and many more.
SCORM FIRST
Enterprise Ready
Kontra’s application security training platform is built for companies of all sizes.
From startups that need a solid understanding of application security issues, all the way to the largest enterprises with complex content & scaling needs, our purpose-built learning management system comes with all the features you’d expect from an enterprise-grade appsec training platform.
Learn application security with the frameworks you love
Front-end
Back-end
Mobile
Embedded
DevOps
KONTRA Builder
Want to convert your historical app sec risks into beautiful interactive training content? Easy! Using our powerful content authoring tool, Kontra Builder, we can help you author immersive and captivating learning experiences that are 10x more interesting and relevant for your developers.
Design, build and deploy SCORM compliant interactive applications
Rapidly prototype & build vulnerability scenarios using the storyline editor.
Configure vulnerable applications using our prebuilt template library or build new ones to develop realistic vulnerability simulations.
Configure helper widgets to showcase what’s happening under the hood.
Add code snippets and build beautiful code walkthroughs to showcase how vulnerabilities manifest at a code level.
Publish your content as SCORM packages or integrate them on our Learning Management System.
Ready to start?
Are you ready to take your developer security training to the next level? Request a personalized demo to learn how KONTRA can help you transform your organization’s application security training program.
🌐 Чек листы безопасности для веб-разработчика
Разрабатывать безопасные и надежные веб-приложения в облаке сложно, очень сложно.
Если вы думаете, что это легко, вы либо высшая форма жизни, либо у вас впереди болезненное пробуждение.
Если вы запускаете MVP и считаете, что можете создать продукт за один месяц, который будет ценным и безопасным, подумайте дважды, прежде чем запускать свой «протопродукт».
Ознакомившись с приведенным ниже контрольным списком, вы можете подтвердить, что пропускаете многие из этих критических проблем безопасности.
Как минимум, будьте честны со своими потенциальными пользователями и дайте им знать, что у вас еще нет готового продукта и вы предлагаете прототип без полного обеспечения безопасности.
Этот контрольный список прост и ни в коем случае не полон.
Я надеюсь, что вы будете серьезно их учитывать при создании веб-приложения.
Пожалуйста, прокомментируйте, если у вас есть какие-либо пункты, которые можно добавить в этот список.
База данных
[ ] Используйте шифрование для данных, идентифицирующих пользователей и конфиденциальные данныех, таких как токены доступа, адреса электронной почты или платежные данные.
[ ] Если ваша база данных поддерживает шифрование в состоянии покоя (например, AWS Aurora), включите его для защиты данных на диске. Убедитесь, что все резервные копии хранятся в зашифрованном виде.
[] Используйте минимальные привилегии для учетной записи пользователя для доступа к базе данных. Не используйте учетную запись root для базы данных.
[ ] Храните и распространяйте секреты, используя хранилище ключей, предназначенное для таких целей, как Vault или AWS Secret Manager. Не создавайте секретных кодов в своих приложениях и НИКОГДА не храните секреты в GitHub.
[ ] Полностью предотвратите SQL инъекцию, используя только подготовленные операторы SQL. Например: если вы используете NPM, не используйте npm-mysql, используйте npm-mysql2, который поддерживает подготовленные операторы.
Развертка
[ ] Убедитесь, что все компоненты вашего программного обеспечения проверены на наличие уязвимостей для каждой версии, переданной в производство. Это включает в себя O/S, библиотеки и пакеты. Это должно быть автоматизировано в процессе CI/CD.
[ ] Обеспечьте безопасность систем разработки с такой же бдительностью, как и для производственных систем. Осуществляйте с борку программного обеспечения из защищенных, изолированных систем разработки.
Аутентификация
[ ] Убедитесь, что все пароли хешируются с использованием соответствующего алгоритма шифрования, такого как bcrypt. Никогда не пишите свую собственную крипту и правильно инициализируйте ее.
[ ] Внедрите простые, но адекватные правила для паролей, которые будут заставлять пользователей использовать длинные случайные пароли.
[ ] Используйте многофакторную аутентификацию для входа в систему всем вашим поставщикам служб.
Защита от отказа в обслуживании
[ ] Убедитесь, что атаки DOS на ваши API не нанесут вред вашему сайту. Как минимум, установите ограничения скорости на API, таких как процедуры входа в систему и генерации токенов.
[ ] Принудительное ограничение размера и структуры данных и запросов, представленных пользователем.
[ ] Используйте смягчение распределенного отказа в обслуживании (DDOS) через глобальный прокси-сервис кеширования, такой как CloudFlare. Это может быть включено в проект, если вы подвергаетесь атаке DDOS.
Интернет-трафик
[ ] Используйте TLS для всего сайта, а не только для форм входа и ответов. Никогда не используйте TLS только для формы входа.
[ ] Файлы cookie должны быть доступны только в режиме httpOnly и быть безопасными, а также иметь область действия и путь.
[ ] Используйте CSP, не допуская небезопасных бэкдоров. Это очень сложно настроить, но стоит того.
[ ] Используйте ответы HSTS для принудительного доступа только по TLS. Перенаправьте все HTTP-запросы на HTTPS на сервере в качестве резервной копии.
[ ] Используйте токены CSRF во всех формах и используйте новый заголовок ответа SameSite Cookie, который исправляет CSRF и для всех новых браузеров.
API-интерфейсы
[ ] Убедитесь, что в ваших общедоступных API нет перечисляемых ресурсов.
[ ] Убедитесь, что пользователи полностью аутентифицированы и авторизованы соответствующим образом при использовании ваших API.
[ ] Используйте проверки в API для обнаружения незаконных или ненормальных запросов, которые указывают на атаки.
Проверки
[ ] Выполните проверку ввода на стороне клиента для быстрой обратной связи с пользователем, но никогда не доверяйте ей.
[ ] Проверять каждый последний бит пользовательского ввода, используя белые списки на сервере. Никогда не вводите пользовательский контент напрямую в ответы. Никогда не используйте пользовательский ввод в выражениях SQL.
Конфигурация облака
[ ] Убедитесь, что все сервисы имеют минимальное число открытых портов. Хотя безопасность через неизвестность не является защитой, использование нестандартных портов усложнит задачу для злоумышленников.
[ ] Организуйте хостинг базы данных и сервисов на частных VPC, которые не видны ни в одной общедоступной сети. Будьте очень осторожны при настройке групп безопасности AWS и пиринговых VPC, которые могут непреднамеренно сделать службы видимыми для общественности. [ ] Изолировать логические сервисы в отдельных VPC и одноранговых VPC, чтобы обеспечить межсервисную связь. [ ] Убедитесь, что все службы принимают данные только с минимального набора IP-адресов. [ ] Ограничьте исходящий IP и трафик портов, чтобы минимизировать APT и «botification». [ ] Всегда используйте пользователей и роли AWS IAM, а не учетные данные root. Инвестируйте в обучение эффективному использованию IAM. [ ] Используйте минимальные права доступа для всех сотрудников и разработчиков. Предоставьте пользователям и ролям IAM минимальные возможности, необходимые для выполнения задачи. [ ] Регулярно меняйте пароли и ключи доступа по заданому расписанию.
Инфраструктура
[ ] Убедитесь, что вы можете делать обновления без простоев. Убедитесь, что вы можете быстро обновить программное обеспечение полностью автоматизированным способом.
[ ] Создайте всю инфраструктуру, используя такой инструмент, как Terraform, а не через облачную консоль. Инфраструктура должна быть определена как «код» и может быть воссоздана одним нажатием кнопки. Не переносите на дух любой ресурс, созданный в облаке вручную – Terraform может затем проверить вашу конфигурацию.
[ ] Используйте централизованное ведение журнала для всех служб. Вам никогда не потребуется SSH для доступа или получения журналов.
[ ] Не пользуйтесь услугами SSH, за исключением одноразовой диагностики. Регулярное использование SSH обычно означает, что вы не автоматизировали важную задачу.
[ ] Не оставляйте порт 22 открытым для каких-либо сервисных групп AWS на постоянной основе.
[ ] Создайте неизменные хосты вместо долгоживущих серверов, которые вы исправляете и обновляете.
[ ] Используйте систему обнаружения вторжений, чтобы минимизировать APT.
Операции
[ ] Отключите неиспользуемые сервисы и серверы. Самый безопасный сервер – это тот, который выключен. Это можно запланировать с помощью таких инструментов, как PowerDown.
Тестирование
[ ] Аудит вашего дизайна и реализации.
[ ] Пройдите тестирование на проникновение – взломайте себя, но также еще попросите кого-нибудь провести тестирование.
Наконец, составьте план
[ ] Разработайте модель угрозы, которая описывает, от чего вы защищаетесь. Она должна перечислить и расставить приоритеты возможных угроз и субъектов.
[] Разработайте практический план по обработке инцидентов безопасности. Однажды он вам понадобится.