Частные API
Моей первой интуицией было предоставление внутреннего ключа API, который предоставил бы доступ ко всей конфиденциальной информации в БД (через частную конечную точку), так же, как ключи разработчика предоставляют доступ кподмножество конечных точек API
Ну, частные конечные точки или частные API не существуют в смысле защиты их только с помощью ключа API.Из веб-приложения вам нужно только увидеть исходный код HTML, чтобы найти ключи API.На мобильных устройствах вы можете увидеть, как просто перепроектировать ключи API в этой серии статей о технологиях безопасности Mobile API.Хотя статьи относятся к мобильным устройствам, некоторые из используемых методов также применимы в API других типов.Я надеюсь, что теперь вы можете увидеть, как кто-то может получить ключ API и злоупотребить им с помощью API, который вы пытаетесь защитить.
Теперь, даже если вы не предоставите ключ API в мобильном приложении или веб-приложении,API все еще доступен для обнаружения, особенно если конечная точка обслуживается тем же API, который используется для других общедоступных конечных точек.Это становится еще проще, если в robots.txt указать, что боты не должны получать доступ к некоторым конечным точкам, потому что это первое место, где хакеры обращают внимание на попытки перечислить векторы атак в ваших API.
Возможные решения
Private API Solution
Какой лучший подход к подобному?Моей первой интуицией было предоставление внутреннего ключа API, который предоставил бы доступ ко всей конфиденциальной информации в БД (через частную конечную точку)
Чтобы иметь частный API, сервер, на котором он размещен, должен бытьзащищен брандмауэром и заблокирован на другом внутреннем сервере, использующем его для закрепления сертификата и, возможно, также по IP-адресу.Чтобы иметь возможность надлежащим образом защитить и заблокировать внутренний сервер, на котором размещен предполагаемый частный API, он НЕ ДОЛЖЕН поддерживать какие-либо публичные запросы.
Закрепление сертификата :
Прикрепление эффективно удаляет «конференцию доверия».Прикладная программа, которая прикрепляет сертификат или открытый ключ, больше не должна зависеть от других - таких как DNS или CA - при принятии решений о безопасности, относящихся к личности партнера.Для тех, кто знаком с SSH, вы должны понимать, что закрепление открытого ключа почти идентично опции SSH StrictHostKeyChecking.SSH все время делал это правильно, и весь остальной мир начинает осознавать достоинства прямой идентификации хоста или службы по их открытому ключу.
Решение для прямого доступа к базе данных
Каков наилучший подход для передачи конфиденциальной информации через внутренние службы?
Лично я предпочел бы получить доступбазы данных непосредственно с другого сервера, и само программное обеспечение базы данных сконфигурировано так, чтобы принимать запросы только от определенных внутренних серверов для конкретных пользователей с меньшими правами, доступными для выполнения необходимых действийКроме того, вы должны использовать блокировку межсетевого экрана и использовать закрепление сертификатов между внутренними серверами.
Заключение
Независимо от того, какое решение вы выберете, разместите свою базу данных с конфиденциальными данными на сервере, на котором размещена только эта база данных.и очень хорошо привязан к вашей внутренней сети.
Любой, кому необходим доступ к этим конфиденциальным данным, ДОЛЖЕН иметь права на чтение только для этой конкретной таблицы базы данных.