Эта статья – седьмая (кажется) в цикле, направленном на донесение базовых технических знаний до продуктовых дизайнеров и проектировщиков. В конце вы найдёте список остальных статей цикла – и крайне рекомендую не останавливаться на прочитанном. Ну или внести их в закладки, как минимум. Ибо вероятность того, что вам когда-нибудь понадобится эта информация, так же велика, как госдолг сами-знаете-кого.
Зачем дизайнеру ИБ?
Да, многие скажут, что информационная безопасность – вообще не задача дизайна. Что за неё отвечают программисты, архитекторы – кто угодно, но не проектировщики и аналитики. Конечно, это не совсем так. Иначе я не стал бы утруждать себя написанием этого текста.
Базовый фундамент безопасности ваших пользователей можно (и нужно) закладывать уже на этапе проектирования. Если изначально дизайнер создаёт уязвимую архитектуру, программистам куда сложнее будет залатать все дыры. Если, конечно, они вообще этим озаботятся.
На что обращать внимание
Например, при проектировании API нужно понимать, какие данные можно "светить", а какие – нет. Классический факап, это когда на клиент (браузер, мобильное приложение) передаётся реальный ID пользователя из базы данных. Не захэшированный GUID, а прям порядковый номер в БД. Это в миллион раз упрощает брутфорс или парсинг вашего сервиса.
Еще один пример – это авторизация. Не заложите грамотные сценарии авторизации и аутентификации – получите кучу проблем. Гарантирую.
У меня есть даже отдельная статья на этот счёт.
Ещё статьи из цикла
Если вы не нашли в цикле чего-то, что ожидали или хотели бы там увидеть – обязательно пишите в комментариях. Буду дополнять.
- Фреймворки – что это такое и какие бывают.