Первый:
Безопасность обменивает все
Пример: Dev Ops невозможен, если безопасность является вашим первым приоритетом без подхода, ориентированного на риск.
Если вы доверяете своим разработчикам и предоставляете им доступ к вашей производственной системе без какого-либо аудита и двухфакторных рабочих процессов, вы столкнетесь с проблемами безопасности.
Секунда:
Вы должны проанализировать свои риски.Риск - это двумерное значение вероятности и воздействия, и если риск слишком высок, вы должны предпринять действия, чтобы снизить риск.
Пример: насколько вероятно, что кто-то взломает ваш API и чтотакое воздействие?
Допустим, что воздействие равно very high, а вероятность равна very low.
Следуя этой матрице, вы имеете умеренный риск.
Если ваше ПО не желает идти на такой риск, вы должны предпринять некоторые действия, чтобы уменьшить его.
Одна идея может заключаться в том, чтобы скрыть спецификацию API, но это только уменьшит вероятность этого риска, верно?И вероятность уже очень низкая.Таким образом, это больше не снижает риск.
Следовательно, вы должны уменьшить воздействие.Ну, это зависит от того, почему воздействие так велико, верно?
С другой стороны: предположим, вы предполагаете, что сценарий "кто-то взломает ваш api" имеет вероятность moderate, когда спецификация и apiэто GA.
Тогда скрытие спецификации может немного уменьшить вероятность.Май с moderate до low.Это уменьшит ваш риск с High risk до Moderate risk.
Вывод: Скрытие спецификации API - это действие, которое уменьшает вероятность того, что кто-то получит доступ к вашему API, не имеяразрешение.
Если вероятность уже очень мала, нет необходимости скрывать спецификации API в отношении проблем безопасности.Могут быть другие причины, чтобы скрыть спецификацию.
Таблица взята из Impact_and_Probability_in_Risk_Assessment