Руководство небольшой компании, в которой я работаю, очень взволновано SaaS и продвигает наш продукт к развертыванию SaaS - меня это беспокоит, потому что часть функциональности продукта основана на том, что пользователи могут использовать бизнес-аналитику. инструменты для написания отчетов по базовой базе данных приложения.
Когда я спрашиваю, как мы планируем предоставить эту функциональность в модели SaaS, меня встречают пустыми взглядами, и в ответ мы просто открываем сервер базы данных в Интернете и позволяем людям запрашивать базу данных, как если бы она работала внутри их корпоративная сеть.
Это пугает меня до смерти, но я не знаю, просто ли я параноик или есть веская причина для беспокойства.
Итак, мой вопрос: можно ли надлежащим образом усилить безопасность сервера базы данных Oracle, чтобы нам не нужно было беспокоиться о том, что он будет открыт в Интернете? И если да, то какие ресурсы мне следует изучить, чтобы научиться этому? В базе данных будет храниться конфиденциальная информация, которую наши клиенты не хотели бы раскрывать миру, и тем не менее предложение о внедрении этой функции в VPN было категорически отклонено.
Мои поиски по укреплению базы данных оракула почти все включали утверждения вроде «Никогда не проделывайте дыру в вашем брандмауэре», так что, возможно, правильный ответ здесь - «Обновите свое резюме как можно быстрее», но я цените любой совет, который вы можете дать.
Открытие базы данных на самом деле не гигант проблема по сравнению с некоторыми другими службами, которые часто доступны для world + dog ... за исключением того, что это сложная система с множеством потенциальных уязвимостей, включая повышение разрешений. Я бы позаботился о том, чтобы вы не открывали базу данных для общедоступных запросов и не запускали ее с требуемым SSL и т. Д. Я бы сказал, что это возможно, но да, вы должны быть параноиком и поддерживать отдельную установку базы данных для общедоступной. Если ваша компания не желает оплачивать лицензионные платежи за это, да, драпать.
Со стороны клиента / службы поддержки прямое подключение к базе данных может быть проблемой, если интернет-провайдер клиента блокирует определенные типы портов или трафика.
В модели SaaS программисты обычно должны писать API, который можно запрашивать из приложения. API такого рода обычно работают через https и предоставляют данные обратно приложению в ответе HTTP. Дополнительный бонус: он работает из любого места, где работает Интернет, ОЧЕНЬ легко кэшировать наборы результатов с использованием memcached или других технологий кэширования для уменьшения нагрузки на сервер db, а http auth довольно хорошо поддерживается и тестируется.
Я бы установил второй сервер базы данных в демилитаризованной зоне, импортировал дампы в эту базу данных и сделал эту базу данных общедоступной.
Я уверен, вы согласитесь, что доступ и безопасность по определению - это компромисс. И перед вами стоит задача сделать доступными конфиденциальные данные.
Короткий ответ: вы можете снизить значительный риск с помощью уловки брандмауэра, надежной сетевой архитектуры, обновленных наборов исправлений, аудита доступа и большого объема резервного копирования.
Управление паролями также представляет собой сложную задачу: часто учетные записи приложений имеют пароли, срок действия которых никогда не истекает, а контроль физического / сетевого доступа обеспечивает защиту бывших сотрудников со знанием паролей от доступа к данным. Если ваш сервер базы данных доступен для всего Интернета, это будет сложно сделать.
Вы, вероятно, также захотите дать определение «мы были скомпрометированы, что нам теперь делать?» стратегия, так что вы уравновешиваете, устанавливаете ожидания для всех участников и имеете план действий, когда ваша удача иссякнет.
Я бы посоветовал использовать либо API, либо веб-службы, при этом предпочтительнее использовать веб-службы, поскольку конечные пользователи (клиенты) подключаются к ним с большей гибкостью.
Часть 2, руководство скажет: «Без ума от этого, нам нужно выйти на рынок СЕЙЧАС!» и не хочу тратить деньги на его разработку.
В части 3 вам нужно убедить руководство, почему открывать базу данных напрямую - это плохо, а затем подготовить кучу официальных документов, отчетов о безопасности и т. Д. Кроме того, если бы я думал об использовании вашего программного обеспечения, а SaaS, Я хотел бы знать все о вашей безопасности, и как только я узнаю, что вы раскрываете базу данных, сделка прекращена.
SaaS - это товар.
Открыть доступ к серверу базы данных в Интернете - не очень хорошо.
Зачем им это нужно разоблачать? Это из-за RPC, и они не хотят использовать статические порты RPC?
Но есть несколько отличных брандмауэров приложений, и если вы заблокируете порт endmapper БД, а затем брандмауэр его - вы можете сделать кое-что с ACL, ограничениями IP и т. Д.
И вам нужно будет провести аудит журналов событий, сканирование уязвимостей и т. Д.
Держите сервер БД надежно за брандмауэром. При необходимости напишите веб-службы, которые размещаются на общедоступном веб-сайте, имеющем туннель к серверу БД. Убедитесь, что веб-службы имеют ограниченный доступ к БД. Если требуется, чтобы они составляли отчеты, тогда веб-службам нужен доступ только для чтения. Я бы, вероятно, создал представления данных, которые хотел представить, и предоставил бы доступ на чтение к ним, а не к самим базовым таблицам.
Как сказал Роб, проверяйте все, запускайте сканирование уязвимостей, включайте регистрацию доступа в самих приложениях веб-служб, чтобы вы могли видеть, кто к чему и когда обращался.
Мы используем несколько приложений SaaS в ходе нашей деятельности, и они делают это двумя способами.
Помимо безопасности, вы должны беспокоиться о производительности в многопользовательской системе. Вы не хотите, чтобы плохо написанный отчет одного пользователя в Crystal влиял на всех остальных пользователей отчетов.