Является ли откладывание проблем безопасности до конца цикла разработки приложений хорошим подходом?

Question

Является ли откладывание проблем безопасности до конца цикла разработки приложений хорошим подходом?

1

Поскольку мы собираемся разработать некоторый открытый API для других приложений для интеграции, кто-то предлагает нам отложить материал безопасности до тех пор, пока методы API не будут выполнены, поэтому у стороннего приложения будет над чем работать! Является ли это хорошим подходом к решению проблемы, или мы должны установить безопасность, а затем разработать сам API?

РЕДАКТИРОВАТЬ:

Проблема здесь в стоимости. Скажем, если у вас это в первую очередь, я думаю, что вам не придется пересматривать API, чтобы вносить изменения из-за материалов безопасности, особенно с сторонним приложением, которое поддерживается другая команда. Если мы задержим его до тех пор, пока все не будет выполнено и не будет интегрировано, другая команда должна изменить и изменить код.

Итак, из вашего опыта, что будет стоить меньше?

Toan Nguyen 21 май 2014, в 07:48

Источник

Теги:

c#

asp.net

security

asp.net-web-api

asp.net-web-api2

3 ответа

1

Безопасность - это проблема CROSSCUTTING, а это значит, что она проникает (и должна) каждый уровень архитектуры. Почему бы не использовать Basic Auth и не использовать ключ с сторонними разработчиками приложений?

Безопасность всегда должна быть проблемой. Это не поможет отложить, если ваши API безупречны, а ваша система безопасности ошибочна.

Aniket Inge 21 май 2014, в 04:11

1

Это зависит от...

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

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

Larsenal 21 май 2014, в 02:43

Ещё вопросы

TaW · Accepted Answer · 2014-05-21T04-56-00.000Z

Вы должны иметь дизайн с самого начала, включая безопасность. Изменение дизайна позже будет стоить намного дороже. Вначале реализация может быть либо отложенной, либо неполной.

Если вы, например, не знаете гранулярность прав доступа, вам придется много переделать, когда позже узнаете, что он должен выходить за пределы доступа к таблице или за пределами SIDU и на самом деле работать на уровне строк.

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