Форум: Форум PHPФорум ApacheФорум Регулярные ВыраженияФорум MySQLHTML+CSS+JavaScriptФорум FlashРазное
Новые темы: 0000000
PHP 5. На примерах. Авторы: Кузнецов М.В., Симдянов И.В., Голышев С.В. Социальная инженерия и социальные хакеры. Авторы: Кузнецов М.В., Симдянов И.В. Самоучитель MySQL 5. Авторы: Кузнецов М.В., Симдянов И.В. PHP Puzzles. Авторы: Кузнецов М.В., Симдянов И.В. PHP на примерах (2 издание). Авторы: Кузнецов М.В., Симдянов И.В.
ВСЕ НАШИ КНИГИ
Консультационный центр SoftTime

Разное

Выбрать другой форум

 

Здравствуйте, Посетитель!

вид форума:
Линейный форум Структурный форум

тема: Как быть уверенным, что админ не воспользуется моим контентом?
 
 автор: Eugene77   (26.02.2012 в 18:47)   письмо автору
 
 

Хочу разместить где-то свой сайт,
но проблема в том, что база данных содержит информацию
значительную по своей ценности в денежном выражении.

Понимющий её ценность человек может предложить админу хостинга выкупить мою базу за N-ю сумму. А я, естественно, не хотел бы чтобы это было возможно.

Существут ли решение моей проблемы?

  Ответить  
 
 автор: cheops   (26.02.2012 в 18:55)   письмо автору
 
   для: Eugene77   (26.02.2012 в 18:47)
 

Можно использовать выделенный сервер.

  Ответить  
 
 автор: Eugene77   (26.02.2012 в 19:09)   письмо автору
 
   для: cheops   (26.02.2012 в 18:55)
 

>Можно использовать выделенный сервер.
1) С выделенного сервера резервные копии не делаются?
2) Если даже у меня будет root-доступ, то разве у другого админа нет возможности прочитать файлы напрямую с обращаясь к диску? Наверно для этих целей даже утилита какая-нибудь имеется.

  Ответить  
 
 автор: cheops   (26.02.2012 в 19:59)   письмо автору
 
   для: Eugene77   (26.02.2012 в 19:09)
 

>1) С выделенного сервера резервные копии не делаются?
Выделенный сервер - это компьютер подключенный к интернет, им распоряжаетесь только вы и сами обо всем заботитесь, в том числе и об резервных копиях. Вам могут установить операционную систему, которую вы сами настраиваете. Ну это если вы его арендуете, а можете своим собственным пользоваться, арендуя только место в дата-цетре: сами покупаете сервер, налаживаете его и везете в дата-центр, где и устанавливаете. Что вы там с сервером делаете в дата-центре не знают, вы управляете им сами. Если сломаете, они ничего делать не будут (да у них и паролей не будут), сами своими ногами поедете в дата.центр чинить свой сервер. Понятно, что если у вас есть выделенный IP-адрес и хороший канал, хотя бы 100Мб, можно вообще сервер никуда не возить, а держать у себя в офисе.

>2) Если даже у меня будет root-доступ, то разве у другого админа нет возможности прочитать
>файлы напрямую с обращаясь к диску? Наверно для этих целей даже утилита какая-нибудь
>имеется.
root, на то и root, что вы сами себе хозяин и можете сменить пароль. Другое дело, что в этом случае вам и помочь никто не сможет, кроме вас самих. Виртуальный хостинг в том числе и поэтому популярен - линуксоиды и сетевые администраторы не на каждом углу валяются, а вам придется выполнять их функции или держать соответствующую штатную единицу, а может и не одну.

PS Вы меряете сервера концепциями виртуального-хостинга, они редко в одном экземпляре держатся, часто целые стойки арендуются, где есть ряд серверов для работы, ряд в резерве, если сломаются основные, ряд для резервных копий... это с одним сервером тяжело - что с ним случись: катастрофа, а когда у вас их десяток (да еще и не в одном дата-центре), резервное копирование, ввод резервных серверов - это не проблема (проблема, конечно, но разрешимая). Если уж загубили операционную систему, что она не откликается, поехали забрали сервер - сунули на его место из резерва и разбираетесь с ним не спеша. При этом персонал дата-центра ни сном ни духом, что там у вас и зачем.

  Ответить  
 
 автор: Eugene77   (26.02.2012 в 20:12)   письмо автору
 
   для: cheops   (26.02.2012 в 19:59)
 

Выделенный сервер - это компьютер подключенный к интернет
А я понял, что речь о VDS/VPS - ошибся.
Целый сервер для моего объёма данных и планируемого трафика - это примерно в 1000 раз больше, чем требуется...
Да и дата-центра поблизости нет (как и Интернета приемлемого)

  Ответить  
 
 автор: cheops   (26.02.2012 в 20:35)   письмо автору
 
   для: Eugene77   (26.02.2012 в 20:12)
 

Тогда плохо дело, так как если вы будете делить сервер с кем-то, как ни крути, потребуется сторонний администратор. Можно шифровать базу данных, но это повлечет за собой изрядные накладные расходы.

  Ответить  
 
 автор: Владимир55   (26.02.2012 в 21:39)   письмо автору
 
   для: cheops   (26.02.2012 в 20:35)
 

А известны реальные случаи, когда админы хостинга что-то продали с сайтов клиентов?

(Вопрос не праздный. Вот прямо сегодня пришло письмо с предложением продать не имеющую аналогов базу медицинских знаний, которую я сам разработал и только в январе разместил на своём сайте. К ней доступ по инвайтам, и я считал это достаточной защитой. Но вопрос о возможности действовать в обход меня, через админа хостинга, даже в голову не приходил!).

  Ответить  
 
 автор: Eugene77   (26.02.2012 в 21:58)   письмо автору
 
   для: Владимир55   (26.02.2012 в 21:39)
 

У меня нет точной информации о том, чтоб админы у клиентов информацию тырили, но
ряд фактов показывает что уж больно на то похоже.

Вот Хеопсу бы я свою базу доверил, а больше просто не знаю к кому ещё обратиться.

  Ответить  
 
 автор: cheops   (26.02.2012 в 22:55)   письмо автору
 
   для: Eugene77   (26.02.2012 в 21:58)
 

Спасибо на добром слове :))), посмотрите в сторону больших американских хостингов (как Владимир55 советует), там тоже много людей, которым с одной стороны ничего не нужно, с другой, повернись по-другому, они сами бы платили бы за то, чтобы в сетях копаться :))). Только хостинг нужно выбирать гигантский - там просто времени на такую ерунду нет и деньги вертятся такие, что не перешибешь.

  Ответить  
 
 автор: cheops   (26.02.2012 в 22:03)   письмо автору
 
   для: Владимир55   (26.02.2012 в 21:39)
 

Не размещали ничего сверх-критичного на сторонних серверах (ну кроме этого форума, который так и так открыт), всегда налаживали инфраструктуру в офисе. Лишь сейчас подумываем об размещении более или менее критической информации на стороннем хосте (удобно, да информация пусть и ценная, но собранная из открытых источников).

PS Сейчас, я смотрю, довольно беспечно к этому делу относятся, а вообще несколько лет назад ходила фраза "вынос серверов за пределы компании (особенно в IT) эквивалентен выносу мозга за пределы тела". Почту хранят прямо на серверах не выгружая на компьютер, я понимаю, почему так делают школьники, у которых компьютера зачастую постоянного нет... но вроде у серьезных дядек и тетек почту умудряются умыкнуть... такое ощущение, то они её прямо на этих yandex.ru и mail.ru и хранят... Когда получат распространение всякие OnLine-офисы вообще страшно подумать, какая информация начнет утекать. А уж про социальные сети и говорить нечего... спец.операции умудряются срывать, да ладно бы я понял в раздолбайской России, в Израиле, где вообще-то серьезное военное противостояние, вроде они-то должны понимать, что за такие вещи можно жизнь поплатиться...

  Ответить  
 
 автор: Владимир55   (26.02.2012 в 22:37)   письмо автору
 
   для: cheops   (26.02.2012 в 22:03)
 

А если хостинг у буржуев взять? Или в Чехии (там многие арендуют)? Наверняка с заграницей сложнее договориться!

Или так: взять два хостинга один - обычный для сайта, например в Москве, а другой в Питере или Новосибирске.

На первом разместить сайт и базу, а на втором некоторые таблицы базы, без которых она неработоспособна.

С двумя хостерами договориться весьма проблематично! Тем более, что имя второго хостера на так то легко узнать!

Как Вам такая идея?

  Ответить  
 
 автор: cheops   (26.02.2012 в 22:49)   письмо автору
 
   для: Владимир55   (26.02.2012 в 22:37)
 

>А если хостинг у буржуев взять? Или в Чехии (там многие арендуют)? Наверняка с заграницей
>сложнее договориться!
Не плохая мысль, но с чехами договорятся, с немцами сложнее, если не сказать невозможно (но спец.службы наоборот с ними язык быстрее найдут, хотя, если молодые держат, черт его знает, кроме того, там много русского коллокейшена), лучше всего американцы, но они на противоположном конце земного шара (далеко).

>Или так: взять два хостинга один - обычный для сайта, например в Москве, а другой в Питере или
>Новосибирске.
>На первом разместить сайт и базу, а на втором некоторые таблицы базы, без которых она
>неработоспособна.
Слишком далеко, даже если это ваши выделенные сервера, придется репликацию тянуть, без полного управления не реально (распределенная база данных - серьезная проблема, даже когда у вас избыток серверов и не стоит проблема безопасности, если же речь об виртуальном хостинге - слишком сложно получается и неустойчиво, будет много головной боли). Что-нибудь простецкое распилить так можно, а чуть более сложное - вам потребуются сервера в полное управление (а это root-доступ, который и так вам позволяет закрыться от всех) и очень внимательно за всем этим хозяйством следить, оперативно и компетентно вмешиваясь в случае проблем с репликацией (а они будут гарантировано).

>С двумя хостерами договориться весьма проблематично! Тем более, что имя второго хостера
>на так то легко узнать!
Вашему коду потребуется согласовывать действия, а следовательно прописать все логины и пароли внутри кода, злоумышленнику достаточно будет получить доступ лишь к одному серверу, со второго он все вытянет. Понятно, что много зависит от архитектуры, но рано или поздно плюнете и пропишите логины и пароли, а быстрее всего просто откажитесь от этой идеи - это не простая достойная задача, даже не для профессионала, если реальной потребности в распределенной базе данных нет - лучше не связываться. Защиты это не прибавляет, скорее наоборот, больше точек входа становится.

  Ответить  
 
 автор: deimand   (27.02.2012 в 00:11)   письмо автору
 
   для: cheops   (26.02.2012 в 22:49)
 

>Слишком далеко, даже если это ваши выделенные сервера, придется репликацию тянуть, без полного управления не реально (распределенная база данных - серьезная проблема, даже когда у вас избыток серверов и не стоит проблема безопасности, если же речь об виртуальном хостинге - слишком сложно получается и неустойчиво, будет много головной боли).

Почему бы в этом случае просто не использовать что-то типа самого простейшего самопального API?

Я раньше можно сказать болел вопросом сокрытия устройства web-приложений и придумал следующее. У меня канал с датацентром 100 Мб/с, что позволяет держать коды вообще дома, а на публичном сервере хранить лишь примитивную часть. Большинство данных можно кэшировать в виде статических файлов, чтобы и домой не обязательно подключаться было, статику ведь нет смысла прятать, раз ее можно в браузер получить, а вот исходные коды тю-тю.

Использовал я примерно следующий код:

<?php

 
#######################################
 ##            ***********            ##
 ## ********************************* ##
 #######################################

 
ini_set("error_reporting""2047");
 
ini_set("display_errors""on");
 
ini_set("soap.wsdl_cache_enabled""0");
 
ini_set("soap.wsdl_cache_ttl""0");

 
header("Content-type: text/html; charset=utf-8");
 
header("X-Content-Type-Options: nosniff");
 
header("X-Frame-Options: SAMEORIGIN");
 
header("X-XSS-Protection: 1; mode=block");

 
session_start();
 
$_SESSION["session_id"] = session_id();

 
$request = array(
                   
"KEY" => 'aaaaaaaaaaaaaa99fec74f494ab6828e' ,
                   
"POST" => $_POST ,
                   
"SERVER" => $_SERVER ,
                   
"COOKIE" => $_COOKIE ,
                   
"SESSION" => $_SESSION
                 
);

 
$host "http://site.ru/soap.wsdl";
 
$setting = array ("trace" => 1"exceptions" => 0);
 
$connect = @new SoapClient($host$setting);

 
$result $connect -> go($request);
 if (
preg_match("/\[примитивный пример разделения php кода от html кода\]/"$result))
 {
   
$code explode("[примитивный пример разделения php кода от html кода]"$result);
   
$php $code[0];
   
$html $code[1];
   eval(
$php);
   echo 
$html;
 }
 else echo 
$result;

?>


А у себя на сервере все еще проще.

<?php

 
class API
 
{
   public static function 
go($_DATA)
   {
     
define('SOAP'true);

     
ob_start();
     include(
'index.php');
     
$buffer ob_get_contents();
     
ob_end_clean();

     return 
$buffer;
   }
 }

 
$server = new SoapServer("soap.wsdl");
 
$server->setClass("API");
 
$server->handle();

?>


Дальнейшее устройство кода почти ни чем не отличается от обычного, за исключением того, что данные приходят не в $_POST, а $_DATA['POST'], а некоторые обработчики приходилось дублировать в виде строк, чтобы можно было запустить их на удаленном сервере.

  Ответить  
 
 автор: cheops   (27.02.2012 в 00:34)   письмо автору
 
   для: deimand   (27.02.2012 в 00:11)
 

Когда народу мало, это все может сработать, но как только чуть-чуть его станет побольше, все ляжет. Это очень в 90-х было популярно, но потом от этого быстро отказались, проблема в том, что в Интернет идет очень много людей, поэтому код не жалко - его еще написать можно и даже лучше, никому чужой код на самом деле за даром не нужен, нужно решение своих проблем и реализация задач. Т.е. нужен код и те, кто его будет постоянно перебирать, реагировать на вызовы (увеличение посещаемости, смены моды, трендов, стандартов). Код, который сам следит хотя бы за производительностью - большая редкость, еще большая редкость, код, который не ломается (особенно со сменой версии серверов).

  Ответить  
 
 автор: Eugene77   (26.02.2012 в 21:54)   письмо автору
 
   для: cheops   (26.02.2012 в 20:35)
 

>Можно шифровать базу данных, но это повлечет за собой изрядные накладные расходы.
А можно про шифрование БД подробней?
Насколько оно эффективно?
Накладные расходы меня не пугают, нагрузка на базу небольшая, да и сама база маленькая по размеру.
В моём случае большей частью - числа.

  Ответить  
 
 автор: cheops   (26.02.2012 в 22:06)   письмо автору
 
   для: Eugene77   (26.02.2012 в 21:54)
 

Хотя нет... не получится, ключ все-равно где-то хранить придется, если кому-то страсть как захочется украсть данные, его это пожалуй только распалит.

  Ответить  
 
 автор: Eugene77   (27.02.2012 в 05:32)   письмо автору
 
   для: cheops   (26.02.2012 в 22:06)
 

>Хотя нет... не получится, ключ все-равно где-то хранить придется, если кому-то страсть как захочется украсть данные, его это пожалуй только распалит.
Понятно, раз от админа не спрятать, придётся искать честного админа.

Пока у меня следующий план:
1) Размещу базу отдельно от всего остального.
2) Создам пользователя с правами только на одно представление, которое выдаёт за раз только один результат поиска.
3) Настрою так, чтобы пользователь этот мог заходить только с одного IP (Это возможно?)
4) Соединение с базой по SSL

В моём случае трудность ещё и в том, что клиентская сторона должна запускаться под Windows.
Некоторые компоненты переделать под Linux пока проблематично.

Тогда, кто бы ни завладел клиентской стороной, он всё одно не сможет получить полную базу, да и будет иметь проблемы так как ему надо будет именно с того же IP ломать.
А это легко заметить по запросам к базе, тогда он рискует попастся.

Насколько реалистичен такой план?

  Ответить  
 
 автор: cheops   (27.02.2012 в 11:42)   письмо автору
 
   для: Eugene77   (27.02.2012 в 05:32)
 

>Настрою так, чтобы пользователь этот мог заходить только с одного IP (Это возможно?)
Да, это возможно, если у вас есть права администратора на хосте с базой данных или администрация этого сервера пойдет вам на встречу или предоставляет интерфейс для создания таких пользователей.

>Насколько реалистичен такой план?
Посмотрите, возможно вас удовлетворит скорость работы, очень многое зависит от количество хостов между серверами и объемом данных, которым они обмениваются.

  Ответить  
 
 автор: Eugene77   (27.02.2012 в 16:04)   письмо автору
 
   для: cheops   (27.02.2012 в 11:42)
 

>>Насколько реалистичен такой план?
>Посмотрите, возможно вас удовлетворит скорость работы, очень многое зависит от количество хостов между серверами и объемом данных, которым они обмениваются.


Я хотел спросить в смысле безопасности.
Так вроде получается свести к одному узкому месту - админу хостинга, точнее 4-м админам (дежурным).
Или ещё остались узкие места?
Можно как-то усовершенствовать?
Ещё как-то уменьшить влияние "человеческого фактора", кроме как взять немецкий хостинг?

  Ответить  
 
 автор: Кузнецов М.В.   (27.02.2012 в 19:17)   письмо автору
 
   для: Eugene77   (27.02.2012 в 16:04)
 

>Ещё как-то уменьшить влияние "человеческого фактора", кроме как взять немецкий хостинг?

Когда у Вас задача стоит в том, чтобы какую-то сверхценную базу сохранить от кражи, то тут надо целую спецоперацию проводить. И не одним человеком. Даже если это ИВ будет.
Сотовики вон и то стонут, а у них системы безопасности неслабые. Банки стонут. Мы как-то экспертами работали по одному банку, у которого все своровали. В Москве тогда были - и это вечное "срочно, срочно, срочно!!!"
Я, конечно, ничего нового Вам не открою следующей фразой. Но таковые вопросы не предмет форумных обсуждений. И дело даже не в деньгах - хотя Ваш вопрос чисто коммерческий, причем сильно - а в том, что даже если кто-то чего-то сильно умное может сказать, то он не будет этого делать на публичной площадке. Неужто я вот скажу систему безопасности того, чем руковожу? А всё иное, когда здесь нельзя говорить, здесь вообще никак, а тут рыбу заворачивали, будет недомолвками. И повторюсь. Это - работа по проведению организации системы безопасности - работа очень серьезная. И даже если кому то станет скучно из спецов и он решит поделиться "военной тайной" бескорыстно, то ему это очень быстро наскучит. Так как это работы даже не на день, хоть ты из-за компьютера не вылазь. И там могут быть тысячи вариантов. Причем таких, которые мало кому снились. К примеру, такой. Это я самый примитивный вариант говорю. Как раз о точно таком же, как Ваш случае. 15 минут на весь разговор. Для которого пришлось переться в Барселону.
И когда школяры пишут - мы обеспечим безопасность - это очень смешно. Да у вас, ребятиши, для начала просто денег не хватит, чтобы обколесить полмира и самолично все посмотреть. И вы будете интернетить... Скрывая за скачанными оттуда высокоумными фразами реальное положение вещей. И не поняв, что нужно брать билет на самолет/поезд (кому что удобнее) и ехать в ту же Чехию, скажем, если Заказчик хочет Чешский хостинг. И всё на месте выяснять. Обязательно посмотрев САМОМУ (Не в том смысле, что Вам именно, а тому человеку, который занимается безопасностью), что и как на том месте происходит.

  Ответить  
 
 автор: Sergeich   (27.02.2012 в 22:16)   письмо автору
 
   для: Eugene77   (27.02.2012 в 16:04)
 

Пользуйтесь крупными американскими хостингами. Там можно и бесплатно место получить. Я как-то подрабатывал там админом, то нагрузка такая была, что вряд ли кто-то подумать мог, чтобы еще в чужом коде копаться.
А вообще с помощью метода терморектального криптоанализа можно любое шифрование обойти.

  Ответить  
 
 автор: cheops   (28.02.2012 в 00:05)   письмо автору
 
   для: Sergeich   (27.02.2012 в 22:16)
 

>Я как-то подрабатывал там админом, то нагрузка такая была, что вряд ли кто-то подумать мог,
>чтобы еще в чужом коде копаться.
Даже писать не стал, но 80% случае примерно так дело и обстоит. Глаза бы ни на чьи секреты не глядели, за своим бы хозяйством уследить.

  Ответить  
 
 автор: Кузнецов М.В.   (28.02.2012 в 08:43)   письмо автору
 
   для: Sergeich   (27.02.2012 в 22:16)
 

>терморектального криптоанализа

Не в обиду. Но мой друган, прочитав это, не выдержал и мне позвонил. Он в плане, как он говорит "высоких наук", имея ввиду программирование, от которого далек но сильно хочет приблизиться :), а по специальности он военный врач, когда таковое увидел, сильно задался вопросом чего ж это такое.
Rectum - жопа. Термо - ну понятно. Любой врач знает, зачем термометр в задницу засовывают. А вот при чем тут криптоанализ? Это когда врач настолько не в себе, что не может температуру на градуснике посмотреть и приходится привлекать специалистов по ректальному криптоанализу?

  Ответить  
 
 автор: antf   (28.02.2012 в 10:38)   письмо автору
 
   для: Кузнецов М.В.   (28.02.2012 в 08:43)
 

Определение термина нашлось в неофициальной энциклопедии выражений российского интернета:

Терморектальный криптоанализатор — прибор для проведения терморектального криптоанализа — экспресс-дешифрования информации любой сложности шифровки в присутствии носителя этой информации. Говоря проще, метод нагретого паяльника в жопе. Считается, что вероятность успешного дешифрования близка к 99,9%

Полная статья: http://lurkmore.to/терморектальный_криптоанализатор

  Ответить  
 
 автор: Eugene77   (28.02.2012 в 11:52)   письмо автору
 
   для: Кузнецов М.В.   (28.02.2012 в 08:43)
 

[/i]Это когда врач настолько не в себе, что не может температуру на градуснике посмотреть и приходится привлекать специалистов по ректальному криптоанализу?[/i]

Я, конечно не такой специалист в области медицины и таких тонкостей, как вы не знаю, но всё равно хохотал от этого термина не знаю почему.

А в дешифрацию я не верю. Если ключ длинный, то обратить современную криптографическую функцию типа AES_ENCRIPT не выйдет. Ну, можно 2 раза прогнать через неё с довеском каким-нибудь - тогда точно труба!

  Ответить  
 
 автор: Кузнецов М.В.   (27.02.2012 в 20:06)   письмо автору
 
   для: Eugene77   (26.02.2012 в 18:47)
 

>Понимающий её ценность человек может предложить админу хостинга выкупить мою базу за N-ю сумму.

Когда Вы не говорите, что за база - по понятным причинам - все ответы будет не теми. Это очевидно. Выделенный сервер тоже не спасет. Когда речь идет об N-ных суммах. Там уже по другому работают.

  Ответить  
 
 автор: Eugene77   (28.02.2012 в 08:52)   письмо автору
 
   для: Кузнецов М.В.   (27.02.2012 в 20:06)
 

>Когда Вы не говорите, что за база - по понятным причинам - все ответы будет не теми. Это очевидно. Выделенный сервер тоже не спасет. Когда речь идет об N-ных суммах. Там уже по другому работают.

Ну, общие слова не очень полезны...

Я просто увлекался (ещё с прежней работы) численным моделированием некоторых процессов.
Теперь выяснил, что кое-что знаю наперёд с высокой вероятностью (редко ошибаюсь).

Из этого можно извечь доход, но я хочу извлечь его сам, или по взаимовыгодному соглашению.

В моём случае ситуация заметно упрощается: база-то динамически меняется, и сама однократная кража её содержимого малоинтересна, хотя структуру хотелось бы сохранить в тайне, всё ж узнать структуру для вора будет недостаточно.

Табличка из нескольких сот даблов и представления ограничивающие доступ к ней для разных пользователей - вот и вся база.

  Ответить  
 
 автор: Кузнецов М.В.   (28.02.2012 в 10:11)   письмо автору
 
   для: Eugene77   (28.02.2012 в 08:52)
 

>Ну, общие слова не очень полезны...
За общими словами скрываются порой неслабые частности.

>Из этого можно извечь доход, но я хочу извлечь его сам

Мы и не думали, что поделитесь :)

  Ответить  
 
 автор: Владимир55   (28.02.2012 в 12:03)   письмо автору
 
   для: Eugene77   (28.02.2012 в 08:52)
 

Некоторые ЦМС предоставляют свои РНР файлы в зашифрованным виде, так что их невозмжно не только изменить, но даже прочесть. Нельзя ли поступить аналогичным образом? Ведь достаточно зашифровать всего один файл, содержащий пароль связи с БД.

  Ответить  
 
 автор: cheops   (28.02.2012 в 12:28)   письмо автору
 
   для: Владимир55   (28.02.2012 в 12:03)
 

Это байт-код, он завязан на архитектуру интерпретатора, поэтому легко подвержен дешифровке - у него задача другая, не шифрование, а ускорение выполнения (да там собственно никакого шифрования нет, просто данные и код преобразованы в бинарный формат). Это только раззадорит злоумышленника.

PS Да и кроме того, у администратора есть пароль для root-доступа MySQL, если дело происходит на его сервере, ему ваши пароли не нужны... Ему даже свой пароль не нужен (это бинарный лог замучаешься чистить потом), он просто файлы базы данных возьмет на флешку (причем даже не с основного сервера, а с репликационного), поправит системный лог и пойдет спокойно с ними дома разбираться. Нет никаких шансов против администратора, чтобы что-то спрятать на его машине, а он бы не смог это извлечь.

  Ответить  
 
 автор: Владимир55   (28.02.2012 в 13:59)   письмо автору
 
   для: cheops   (28.02.2012 в 12:28)
 

нет никаких шансов против администратора, чтобы что-то спрятать на его машине, а он бы не смог это извлечь.

Жаль, коли так.

  Ответить  
 
 автор: Кузнецов М.В.   (28.02.2012 в 18:33)   письмо автору
 
   для: Владимир55   (28.02.2012 в 13:59)
 

>[i]нет никаких шансов против администратора, чтобы что-то спрятать на его машине, а он бы не смог это извлечь.
>
>Жаль, коли так.[/i]

Это так. Ровно так же, как если тебе в голову вложить медицинские знания, и потом удивляться тому, что ты их используешь. Даже если кому-то когда-то этого не хочется (на войне, допустим).

  Ответить  
 
 автор: Владимир55   (11.03.2012 в 19:36)   письмо автору
 
   для: Eugene77   (26.02.2012 в 18:47)
 

Появились хостинги с применением дополнительных мер по защите информации, в частности выполняющие требования Закона 152-ФЗ.

Используется оборудование, сертифицированное ФСТЭК и ФСБ России, ограничен доступ персонала к оборудованию, ведется учет используемых физических носителей информации, СУБД MySQL индивидуальна для каждого пользователя, FireWall / Фильтрация пакетов, копирование дважды в день, протоколирование действий администраторов.

  Ответить  
 
 автор: cheops   (11.03.2012 в 20:06)   письмо автору
 
   для: Владимир55   (11.03.2012 в 19:36)
 

Все-равно самому лично проверять надо, что и как... ФСБ их один раз сертифицирует, потом скорее всего у серверной не остаются двое часовых с наганами, а случись какая авария в серверную все-равно заходить придется - не манипуляторами же они сервера чинят :)?.

[поправлено модератором: обсуждение политики вынесено в отдельную тему IT и политическая борьба]

  Ответить  
Rambler's Top100
вверх

Rambler's Top100 Яндекс.Метрика Яндекс цитирования