|
Действия ...
Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
24.12.2012, 04:38
|
|||
|---|---|---|---|
|
|||
Безопасность данных на хостинге |
|||
|
#18+
Добрый день, Подскажите варианты СУБД для моего случая (если вопрос уже обсуждался - дайте ссылку где именно). Имеем многопользовательское приложение, следующей схемы БД (MS SQL Server 2008) -> Сервер (WCF сервис под IIS) -> Клиенты (есть веб-клиенты, есть десктоп-клиенты от 1 до 20 подключений в общей сложности). Все запросы Сервера к БД выполняются через определенного пользователя (назовем его Вася), используя SQL аутентификацию. Учитывая, что серверная часть (БД + Сервер) будут устанавливаться на хостинге, необходимо сделать так, чтобы никто (никакие SA, Администраторы и прочие), кроме Васи не мог прочитать (и желательно поменять) данные, хранящиеся в БД. Как я поняла из раздела, посвященного MS SQL, эта задача не решается средствами данной СУБД. Поэтому прошу посоветовать другую. Желательно такую, которая работала бы под виндой (хотя и необязательно). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
24.12.2012, 11:21
|
|||
|---|---|---|---|
Безопасность данных на хостинге |
|||
|
#18+
hippos, Какая редакция на хостинге? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
24.12.2012, 12:06
|
|||
|---|---|---|---|
Безопасность данных на хостинге |
|||
|
#18+
hippos, ну у Оракла есть такие средства: Database Vault - это опция СУБД Oracle , которая обеспечивает возможность ограничивать или полностью исключать доступ к данным приложений со стороны администратора базы данных (DBA), обеспеченивает доступ к данным на основе динамически настраиваемых правил, повышает защищенность объектов БД от несанкционированных изменений и разделение полномочий пользователей в соответствии с их функциональными обязанностями и надежный внутренний контроль. Там есть всякие фичи, чтобы доступ ограничивать и по расписанию (например, с 08 до 18), и по Айпишникам. Но эта опцияч самой дорогой редакции Оракла EE. В принципе, таv у них у буржуа есть какие-то требования безопасности чуть-ли не на уровне закона, и у Оракла типа есть средства, чтобы выдержать аудит этих требований. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
24.12.2012, 13:30
|
|||
|---|---|---|---|
Безопасность данных на хостинге |
|||
|
#18+
Официальная рекомендация микрософта - шифрование. Можете погуглить эту тему по ключевым словам mssql pci dss. вот выдержка из документа микрософт: авторMicrosoft SQL Server® 2008 Encryption and Key management. When you store cardholder data in SQL Server, you can implement one of three built-in capabilities in SQL Server 2008 to protect cardholder data: SQL Server 2008 Transparent Data Encryption (TDE) offers full data encryption. TDE encrypts all database files including data files, log files, and backup files. SQL Server 2008 cell level encryption offers encryption of individual columns and cells. The use of cell level encryption requires modifications to client applications to handle the explicit encryption. SQL Server 2008 Extensible Key Management (EKM) offers split encryption key ownership. EKM provides a robust key management solution that ensures you can encrypt all data using TDE. EKM reduces issues with managing a potentially complex key management solution in SQL Server. For more information, see the Microsoft SQL Server 2008 Web site, or Deploying SQL Server 2008 Based on Payment Card Industry Data Security Standards (PCI DSS) (PDF) by Parente Randolph. Если кратко, то стандарт карточной безопасности pci dss требует, что-бы определенные данные в БД были защищены и недоступны для неавторизованного доступа третими лицами, в том числе и DBA. В вашем случае может проще будет не давать пароль от dba хостеру? У оракла механизмы понавороченнее,но я не спец по ораклу. Всегда было интересно, как у них реально устроен этот механизм, ибо помимо дба там есть спец-менеджер по безопасности, т.е. кто-то в системе будет, кто рулит этим механизмом, и совсем просто так отдать все ключи на сторону не получится. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
24.12.2012, 13:36
|
|||
|---|---|---|---|
Безопасность данных на хостинге |
|||
|
#18+
вот в догонку ссылочка: http://www.sqlmag.com/content1/topic/securing-credit-card-data-through-sql-server-2008/catpath/sql-server-2008/page/3 В любом случае, дешево этоне будет на любой субд :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
24.12.2012, 13:36
|
|||
|---|---|---|---|
Безопасность данных на хостинге |
|||
|
#18+
Ggg_oldЕсли кратко, то стандарт карточной безопасности pci dss требует, что-бы определенные данные в БД были защищены и недоступны для неавторизованного доступа третими лицами, в том числе и DBA. В вашем случае может проще будет не давать пароль от dba хостеру?В случае с MSSQL "просто не давать пароль о DBA" не работает: остановка сервера -> копирование файлов БД -> монтирование копии файлов БД на другом сервере (с известным паролем DBA) -> данные "вскрыты"... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
24.12.2012, 15:52
|
|||
|---|---|---|---|
|
|||
Безопасность данных на хостинге |
|||
|
#18+
Гораздо дешевле будет не размещать БД на хостинге. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
24.12.2012, 16:13
|
|||
|---|---|---|---|
Безопасность данных на хостинге |
|||
|
#18+
Dimitry SibiryakovГораздо дешевле будет не размещать БД на хостинге. Дешевле - нет. Безопаснее - да. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
24.12.2012, 16:26
|
|||
|---|---|---|---|
Безопасность данных на хостинге |
|||
|
#18+
или иметь два независмых хостинга, один для субд, второй для БД, что-бы все ключи шифрования были физически разнесены и не доступны для для одного админа. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
24.12.2012, 17:36
|
|||
|---|---|---|---|
|
|||
Безопасность данных на хостинге |
|||
|
#18+
hipposУчитывая, что серверная часть (БД + Сервер) будут устанавливаться на хостинге, необходимо сделать так, чтобы никто (никакие SA, Администраторы и прочие), кроме Васи не мог прочитать (и желательно поменять) данные, хранящиеся в БД. При заведении пользователя в отдельную табличку кладете зашифрованный его паролем мастер-пароль работы с БД. Причем шифрацию лучше не делать на сервере провайдера. А все остальные поля (ну или сильно критичные) БД шифруете мастер-паролем. Соответственно переопределяете нужные методы в ORM. Прости-прощай поиск по подстроке. :) P.S. Не пользуйтесь хостером которому не доверяете. Учитывая, что Администратор хостинга может, перехватывать и подменять трафик между клиентом с сервером приложений (а так же подменять код сервера приложений), то при наличии у него злых намерений, он может утянуть клиентский пароль или встроить логгер мастер пароля. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
25.12.2012, 16:59
|
|||
|---|---|---|---|
|
|||
Безопасность данных на хостинге |
|||
|
#18+
Сергей Арсеньев... P.S. Не пользуйтесь хостером которому не доверяете....это фантастика доверять нельзя никому, особенно долгосрочно, даже себе таким образом никакого доверия не бывает . бывает соотношение риск/цена, в некоторых крайних случаях именуемое "доверием" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
start [/forum/topic.php?fid=35&tablet=1&tid=1552493]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
50ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
58ms |
get tp. blocked users: |
2ms |
| others: | 240ms |
| total: | 397ms |
| 0 / 0 |
