Клиент-серверная безопасность сокета
Можно использовать the Row_Number() функция. Его используемый следующим образом:
SELECT Row_Number() OVER(ORDER BY UserName) As RowID, UserFirstName, UserLastName
FROM Users
, От которого это приведет к набору результатов с RowID поле, между которым можно использовать для страницы.
SELECT *
FROM
( SELECT Row_Number() OVER(ORDER BY UserName) As RowID, UserFirstName, UserLastName
FROM Users
) As RowResults
WHERE RowID Between 5 AND 10
и т.д.
8 ответов
Ваши коллеги наивны.
Одна громкая атака произошла на Heartland Payment Systems , процессор кредитных карт, который, как можно ожидать, будет чрезвычайно осторожен в вопросах безопасности. Предполагая, что внутренняя связь за их брандмауэром безопасна, они не смогли использовать что-то вроде SSL для обеспечения своей конфиденциальности. Хакеры могли подслушивать этот трафик и извлекать конфиденциальные данные из системы.
Вот другая история с небольшим дополнительным описанием самой атаки:
Описанная Болдуином как "весьма интересная" изощренная атака ", - говорит он. было сложно узнать точно как это случилось. Судебные бригады обнаружил, что хакеры "хватают номера с вредоносным сниффером, поскольку прошли через нашу платформу обработки ", - говорит Болдуин. "К сожалению, мы уверен, что имена держателей карты и числа были раскрыты. "Данные, в том числе транзакции по карте отправлены Внутренняя обработка Heartland платформа, отправляется в незашифрованном виде, он объясняет: "Поскольку транзакция обрабатывается, он должен быть в незашифрованном виде форма для получения запроса авторизации out. "
Внутри брандмауэра вашей компании вы достаточно защищены от прямых хакерских атак извне. Однако статистика, которую мне не составит труда найти, утверждает, что большая часть ущерба данным бизнеса наносится изнутри. По большей части это просто несчастный случай, но есть разные причины, по которым сотрудники недовольны и остаются незамеченными; и если ваши данные являются конфиденциальными, они могут нанести вред вашей компании.
Существует также множество законов о том, как обрабатывать личные данные. Если обрабатываемые вами данные относятся к такому типу, небрежное обращение с ними в вашей компании также может привести к судебному разбирательству.
Решение состоит в использовании SSL-соединений. Вы хотите использовать для этого предварительно упакованную библиотеку.
SSL обеспечивает как шифрование, так и аутентификацию. В Java он встроен в , а OpenSSL - широко используемая библиотека для C / C ++.
Вы можете многое сделать, чтобы предотвратить атаку человека в середине. Для большинства внутренних данных в защищенной брандмауэром / IDS сети вам действительно не нужно защищать Однако, если вы действительно хотите защитить данные, вы можете сделать следующее:
- Использовать шифрование PGP для подписи и шифрования сообщений
- Шифровать конфиденциальные сообщения
- Используйте хэш-функции, чтобы убедиться, что отправленное сообщение не было отправлено изменен.
Это хорошая стандартная операционная процедура для защиты всех данных, однако защита данных требует очень больших затрат. При использовании защищенных каналов вам необходимо иметь центр сертификации и обеспечивать дополнительную обработку на всех машинах, участвующих в обмене данными.
Практически каждое «важное» приложение, которое я использовал, полагается на SSL или другую методологию шифрования.
Тот факт, что вы находитесь в интрасети, не означает, что у вас может не быть вредоносного код, работающий на каком-то сервере или клиенте, который может пытаться перехватить трафик.
Вы параноик. Вы говорите о передаче данных по, в идеале, защищенной внутренней сети.
Можно ли обнюхать информацию? Да, может. Но его обнюхивает кто-то, кто уже взломал сетевую безопасность и проник в брандмауэр. Это можно сделать бесчисленными способами.
По сути, для большинства предприятий VAST нет причин для шифрования внутреннего трафика. Почти всегда есть гораздо более простые способы получения информации изнутри компании, даже не прибегая к «обнюхиванию» сети. Большинство таких «атак» исходят от людей, которые просто авторизованы для просмотра данных и уже имеют учетные данные.
Решение состоит не в том, чтобы зашифровать весь ваш трафик, а в отслеживании и ограничении доступа, так что если какие-либо данные будут скомпрометированы, легче определить, кто это сделал и к чему у них был доступ.
Наконец, учтите, системные администраторы и администраторы баз данных в любом случае в значительной степени имеют карт-бланш на всю систему, поскольку неизбежно кому-то всегда нужен такой доступ. Просто непрактично все зашифровать, чтобы уберечь от посторонних глаз.
Наконец, вы много шумите по поводу того, что так же вероятно написано на липкой наклейке внизу чьего-то монитора.
Есть ли у вас пароли к вашим базам данных? Я, конечно, надеюсь, что ответ будет положительным. Никто не поверит, что защита базы данных паролем - это излишняя паранойя. Почему бы вам не иметь хотя бы такой же уровень безопасности * для одних и тех же данных, передаваемых по вашей сети. Как и незащищенная БД, незащищенный поток данных по сети уязвим не только для сниффинга, но также может изменяться злоумышленником. Я бы так сформулировал обсуждение.
* Под тем же уровнем безопасности я подразумеваю использование SSL, как предлагали некоторые, или просто шифрование данных с помощью одной из множества доступных библиотек шифрования, если вы должны использовать необработанные сокеты.
Злоумышленник, имеющий доступ к устройству в вашей сети, которое предлагает ему возможность прослушивать весь трафик или трафик между клиентом и сервером является минимально необходимым.
В любом случае, если злоумышленник уже находится внутри, обнюхивание должно быть лишь одной из проблем, которые вы должны принять во внимание.
Я знаю не так много компаний, которые используют безопасные сокеты между клиентами и серверами внутри интрасети, в основном из-за более высокой стоимости и более низкой производительности.