Введение
Подход к разработке программного обеспечения
Безопасность по умолчанию в разработке программного обеспечения означает, что программные продукты и функциональные возможности разрабатываются с учетом фундаментальной безопасности. Альтернативные стратегии, тактики и шаблоны обеспечения безопасности рассматриваются на начальном этапе проектирования программного обеспечения, лучшие из них выбираются и реализуются посредством архитектуры, а также используются в качестве руководящих принципов для разработчиков. Рекомендуется также использовать стратегические шаблоны проектирования, оказывающие положительное влияние на безопасность, даже если изначально они не были разработаны с этой целью. Безопасность по умолчанию все чаще становится основным подходом к разработке, обеспечивающим безопасность и конфиденциальность программных систем. При этом подходе безопасность учитывается и интегрируется в систему на каждом уровне, начиная с разработки надежной архитектуры. Решения по проектированию архитектуры безопасности основываются на известных стратегиях, тактиках и шаблонах безопасности, определенных как повторно используемые методы для достижения конкретных требований к качеству. Тактики и шаблоны безопасности предоставляют решения для обеспечения необходимой аутентификации, авторизации, конфиденциальности, целостности данных, приватности, подотчетности, доступности, безопасности и неотрекаемости, даже при атаке на систему. Для обеспечения безопасности программной системы важно не только спроектировать надежную архитектуру безопасности, но и адаптировать обновленные стратегии, тактики и шаблоны безопасности к процессу разработки программного обеспечения для поддержания постоянного уровня безопасности.
Ожидайте нападения .
Следует исходить из предположения, что вредоносные атаки на программное обеспечение неизбежны, и принимать меры для минимизации их последствий. Необходимо учитывать возможность возникновения уязвимостей безопасности, а также обработку некорректного пользовательского ввода. Тесно связанной с этим является практика применения принципов качественного проектирования программного обеспечения, таких как Domain-Driven Design или облачная архитектура, для повышения безопасности за счет снижения вероятности ошибок, приводящих к уязвимостям, даже если эти принципы изначально не разрабатывались с учетом требований безопасности.
Избегайте безопасности через темноту .
Как правило, хорошо спроектированные системы не полагаются на секретность. Зачастую секретность снижает количество злоумышленников, отбивая охоту у части потенциальных атакующих. Логика проста: увеличение сложности для атакующего и, соответственно, усилий, необходимых для компрометации системы, может их остановить. Хотя эта техника и снижает изначальные риски, практически бесконечное множество атакующих и методов, применяемых со временем, рано или поздно приведет к провалу большинства мер секретности. И хотя это не является обязательным условием, настоящая безопасность обычно подразумевает, что любой желающий может знать и понимать принципы работы системы, поскольку именно это делает её безопасной. Преимущество такого подхода в том, что к коду имеют доступ многие разработчики, что повышает вероятность обнаружения ошибок (как гласит закон Линуса). Недостаток же заключается в том, что злоумышленники также могут получить доступ к коду, что облегчает им поиск уязвимостей. Однако, общепринято считать, что преимущества открытого кода перевешивают его недостатки.
Мало привилегий
Кроме того, важно, чтобы все работало с минимально необходимыми привилегиями (см. принцип наименьших привилегий). Например, веб-сервер, работающий от имени администратора ("root" или "admin"), может иметь возможность удалять файлы и пользователей. Уязвимость в такой программе, следовательно, может поставить под угрозу всю систему, в то время как веб-сервер, работающий в изолированной среде и имеющий только те привилегии, которые необходимы для работы с сетью и файловой системой, не сможет скомпрометировать систему, на которой он запущен, если только сама среда вокруг него не имеет уязвимостей.
Методологии
Безопасная разработка должна рассматриваться на всех этапах жизненного цикла разработки (независимо от выбранной методологии). Существуют готовые методологии разработки, основанные на принципе "Secure By Design" (например, жизненный цикл разработки безопасности Microsoft).
Архитектура сервера/клиента
В архитектуре «клиент-сервер» программа на другом конце может оказаться неавторизованным клиентом, а сервер клиента – неавторизованным сервером. Даже если они авторизованы, атака «человек посередине» может скомпрометировать связь. Зачастую самый простой способ обойти защиту клиент-серверной системы – не атаковать напрямую механизмы безопасности, а обойти их. Атака «человек посередине» – простой пример этого, поскольку её можно использовать для сбора данных, необходимых для выдачи себя за пользователя. Поэтому важно учитывать шифрование, хеширование и другие механизмы безопасности при проектировании, чтобы собранная у потенциального злоумышленника информация не позволила получить доступ. Еще одним ключевым аспектом проектирования безопасности клиент-серверных систем является применение хороших практик кодирования. Например, следование известной структуре проектирования программного обеспечения, такой как «клиент-брокер», может помочь создать хорошо структурированную систему с надежным фундаментом. Более того, если программное обеспечение планируется модифицировать в будущем, особенно важно, чтобы оно основывалось на логичном разделении между клиентом и сервером. Это связано с тем, что если программист не сможет четко понять динамику программы, он может случайно добавить или изменить что-то, что приведет к уязвимости в системе безопасности. Даже при самом продуманном дизайне это всегда возможно, но чем выше стандартизация проекта, тем меньше вероятность подобной ошибки.