Я запускаю Apache Tomcat на сервере Windows Server, и у меня есть данные, хранящиеся в базе данных mySQL. Как я могу предотвратить, чтобы администратор сервера мог видеть любые данные?
Ответ 1
Вы не можете сделать это. Пользователь «Администратор» на машине Windows имеет полный контроль над этой машиной. Кто-то, вероятно, предложит вам зашифровать данные в базе данных. Предполагая, что ключи для шифрования находятся где-то на этом компьютере (поскольку вы хотите, чтобы приложение имело к ним доступ), «Администратор» может просто взять этот ключ и расшифровать данные. Кто-то еще предложит использовать какие-то разрешения на файлы. Это тоже не сработает – «Администратор» может просто изменить их.
Если вы не можете предоставить пользователю «Администратор» ограниченную учетную запись, с помощью которой он может выполнять все свои повседневные действия, но при этом не является «Администратором», единственный ответ – «не храните там такие данные». Любой «ответ», включающий сохранение пользователем «Администратор» своих прав «Администратора», не даст вам никакой реальной защиты.
Я ответил на вопрос автора с технической точностью в отношении привилегий, предоставляемых группе «Администраторы» Windows. Конечно, можно потратить сколько угодно времени на «настройку» стандартных разрешений безопасности в операционной системе, чтобы попытаться либо (а) лишить группу «Администраторы» привилегий, эквивалентных root (что, как я полагаю, Microsoft запрещает делать), либо (б) создать менее привилегированную группу, которая могла бы выполнять все необходимые повседневные функции администрирования сервера, но в противном случае не была бы «Администратором».
Если только потребности группы в «администрировании сервера» не являются очень базовыми, я бы предположил, что это окажется на неизведанной и недокументированной территории. Возможно, вам нужен «администратор сервера», который может выполнять только очень простые операции с серверным компьютером, а пароль «администратора» может быть установлен на произвольно сложную строку и храниться в запертом сейфе. Это одна из возможных стратегий, если бизнес-требования к «администратору сервера» позволяют это сделать. Если требования автора более сложны, я ожидаю, что потребуется изменить множество ACL (в файловой системе, реестре, глобальном менеджере объектов и менеджере управления службами, по крайней мере), чтобы предоставить члену группы, не являющемуся «администратором», возможности, близкие к возможностям члена группы «администраторов». Что также потеряет полезность хорошо известного идентификатора BUILTIN\Administrators SID. Я буду шокирован, если в ОС Windows NT не существует некоторых предположений, заложенных довольно глубоко в ОС Windows NT, относительно привилегий, назначаемых членам группы «Administrators». Попытка отобрать привилегии у группы BUILTIN\Administrators, на мой взгляд, приводит к нестабильности и проблемам с ОС.
Аудит того, что нарушение произошло, не смягчает того, что нарушение произошло. Вы можете знать, что кто-то нарушил конфиденциальность, но никакой механизм аудита не сможет сказать вам, сколько копий конфиденциальных битов было сделано после того, как конфиденциальность была нарушена. Это булева величина — либо конфиденциальность была нарушена, либо нет. Аудит может сказать вам это, и ничего больше. Предприятие может пытаться «обеспечить безопасность» в рамках любой «деловой политики», но если эта «деловая политика» не согласуется с тем, как работает код и реальность, она не имеет смысла.
Ответ 2
В общем, вы можете сделать так, чтобы административные учетные записи не могли делать что-либо, но администраторы могут в общем случае разрешить это, в любом случае.
Например, вы можете запретить доступ на чтение к каталогу для пользователя Administrator, но администратор может снова дать себе доступ, если захочет. Поэтому, я думаю, вы можете (но не уверен), просто запретить доступ на чтение к указанным базам данных, отредактировав привилегии MySQL для пользователя root в базе данных MySQL. Но это не настоящая безопасность. Или вы можете не давать администратору никаких паролей MySQL, но они, вероятно, смогут найти способ просмотреть данные, если у них есть доступ к серверу (или даже сбросить пароль root).
Ответ 3
Это одна из причин, по которой на моей работе сисадминов так тщательно проверяют. Каждый в конечном итоге должен доверить свои данные нам, и у каждого свои требования к «доверию». В некоторых системах можно заблокировать системного администратора, но Windows не является такой системой. Есть некоторые вещи, которые можно сделать на уровне приложений, чтобы скрыть данные от любопытных системных администраторов, например, использование таблиц с зашифрованными данными. Однако это зависит от того, что ключи шифрования и данные находятся в разных доменах системных администраторов, иначе в этом нет особого смысла. В качестве примера можно привести приложение Tomcat/PHP, работающее на сервере Linux под руководством системных администраторов Linux, с базой данных на MS-SQL под руководством системных администраторов Microsoft. Предполагая, что администраторы Linux/MS не вступают в сговор, данные с меньшей вероятностью могут быть подсмотрены.
Ответ 4
Большинство основных операционных систем (Linux, Windows, Mac OS X) не могут сделать это напрямую. Всегда есть учетная запись, которая может делать все в системе (Администратор или root), и эта учетная запись необходима для многих административных задач. Обойти это невозможно.
Чтобы сделать это возможным, вам нужно что-то вроде многоуровневой безопасной ОС, или ОС, поддерживающей обязательный контроль доступа. Что-то вроде SELinux или Trusted Solaris, или Mandatory Integrity Control в Windows Vista. Тем не менее это очень сложно настроить, и могут возникнуть проблемы совместимости с приложениями, которые не были написаны с учетом ограничений. И в конечном итоге кто-то все равно должен иметь доступ для изменения настроек безопасности. Поэтому, хотя технически это возможно, вам следует тщательно оценить, стоит ли это дополнительных сложностей и затрат.
Ответ 5
Шифрование/дешифрование данных на стороне клиента, когда данные поступают на сервер или уходят с него, они всегда зашифрованы. На стороне клиента данные шифруются только тогда, когда пользователь предоставляет соответствующую парольную фразу или ключи.
Создайте клиентскую программу, которая шифрует данные перед отправкой, или скопируйте код из проекта управления паролями ClipperZ с открытым исходным кодом. ClipperZ использует javascript для шифрования в браузере. Излишне говорить, что используйте только очень заблокированный веб-браузер с песочницей selinux и профилем firefox, специально настроенным только для расчета заработной платы. Не электронную почту. Ни для чего другого. Вы даже можете рассмотреть возможность шифрования на сервере, чтобы смягчить некоторые формы руткитов на стороне клиента — особенно «человек в браузере».
Security
