Безопасность HIPAA ePHI Шифрование

Question

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

Что мне нужно сделать: 1. Хранить HIPAA или ePHI (.pdf|.gif|.jpg|.doc) 2. Надежный контроль доступа 3. Поддержка большого количества пользователей и файлов (более 1 миллиона) 4. Полная Аудиторские отчеты (о, ePhi, ты такая боль) 5. Шифрование

Предлагаемые решения
0) Разместите веб-приложение на защищенном выделенном сервере за брандмауэром.

1) Сохраните файлы в файле с именем "secure_files/", а затем используйте mod_rewrite, чтобы ограничить доступ к этому каталогу.

Что-то на линии:

#Removes access to the secure_files folder by users.
RewriteCond %{REQUEST_URI} ^secure_files.*
RewriteRule ^(.*)$ /index.php?/$1 [L]

Затем используйте php-скрипт, чтобы открыть файлы, если у пользователя есть для этого права. Так что я могу просто использовать:

------
-SQL
------

------
- create files table
-----
CREATE TABLE `files` (
id INT NOT NULL AUTO_INCREMENT,
file_name VARCHAR(50) NOT NULL,
PRIMARY KEY('id')
);

------
- create files table
-----
CREATE TABLE `privileges` (
uesr_id INT NOT NULL,
file_id INT NOT NULL,
);

------
- create users table
-----
CREATE TABLE `users` (
id INT NOT NULL AUTO_INCREMENT,
name VARCHAR(20) NOT NULL,
email VARCHAR(50) NOT NULL,
password CHAR(40) NOT NULL,
PRIMARY KEY('id')
);

<?php
public function get_user_files($filename)
{
   //this is set during login
   $user_id = $this->session->userdata('user_id');

   //check to see if the user has privileges to access the file and gets the file name
   $query = $this->db->join('privileges','privileges.id = files.id')
                     ->select('files.file_name')
                     ->where('privileges.user_id',$user_id)
                     ->where('files.file_name',$file_name)
                     ->limit(1)
                     ->get('files');

    $file = $query->row()->files.file_name;

   if($file)
   {
    //user has privileges to access the file so include it
    $handle = fopen($file, "rb");
    $data['file'] = fread($handle, filesize($file));
    fclose($handle);
   }
  $this->load->view('files',$data);
}
?>

2) Используйте класс сеансов CI, чтобы добавить "пользователя" в сеанс.

Контроллер проверяет, установлен ли сеанс:

<?php
public function __construct()        
    {
        parent::__construct();

        if($this->secure(array('userType' => 'user')) == FALSE)
        {
            $this->session->set_flashdata('flashError', 'You must be logged into a valid user account to access this section.');
            $this->session->sess_destroy();
            redirect('login');
        }
    }    

function secure($options = array())
    {            
        $userType = $this->session->userdata('userType');

        if(is_array($options['userType']))
        {
            foreach($options['userType'] as $optionUserType)
            {
                if($optionUserType == $userType) return true;
            }
        }
        else
        {
            if($userType == $options['userType']) return true;
        }
        return false;
    }
?>

3) Поверните круговой прием между несколькими веб-серверами. Я никогда не делал этого, поэтому понятия не имею, как это сделать. Я понятия не имею, как бороться с несколькими серверами баз данных. Есть идеи / предложения?

4) Использовать стандартный аудит базы данных Oracle Enterprise. Я хотел бы использовать MySQL, но я не могу найти поддержку аудита. Я мог бы использовать MySQL и использовать PITA. Кто-нибудь использовал точечную архитектуру (PITA) с MySQL? можешь поделиться своим опытом?

5) Очевидно, что я могу хэшировать пароли с односторонним хэшированием. Но нужно ли мне все шифровать? Также я не вижу, как AES_ENCRYPT(str,key_str) вообще улучшает secuirty. Я думаю, что это может помешать администратору смотреть на базу данных? Можно / нужно зашифровать все в папке "secure_files/"? Могу ли я просто использовать полное шифрование диска, как BitLocker?

В принципе, могу ли я достичь уровня безопасности онлайн-банка с помощью php и CI? Можете ли вы сделать какие-либо другие предложения, кроме бесполезных предложений "ваш идиот, платите эксперту, потому что вы ничего не знаете"?

Спасибо, что нашли время, чтобы прочитать это.

---

принятый от Redux Auth

Что касается одностороннего хеширования. Моя ошибка в том, что я сказал шифрование. Я обычно делаю что-то похожее на:

salt_length = '9'; } открытый хэш функции ($password = false) { $salt_length = $this->salt_length; if ($password === false) { return false; } $salt = $this->salt(); $ пароль = $ соль. substr(хеш ('sha256',$salt . $password), 0, -$salt_length); вернуть $ пароль; } приватная функция salt() { return substr(md5(uniqid(rand(), true)), 0, $this->salt_length); } }?>

Answer 1

Изменить: Шифрование конфиденциальных данных в базе данных SQL защищает от 3 основных угроз.

1. Внутренние угрозы:

   Системный админ и разработчики.

2. SQL-инъекция:

   Если ваша база данных настроена правильно, SQL-инъекция должна предоставить злоумышленнику только доступ к базе данных приложения, и больше ничего. В MySQL убедитесь, что вы отозвать FILE привилегированный, поскольку это может быть использовано для чтения жестко запрограммированного ключа или файла конфигурации.

3. Еще более безопасные резервные копии:

   Безопасность в слоях.

Очевидно, что я могу зашифровать пароли с помощью одностороннего хеша.

Шифрование - это не то же самое, что хеширование. Шифрование подразумевает, что существует способ расшифровки данных. Использование функции шифрования паролей является уязвимостью, признанной CWE-257. Пароли всегда должны использовать соленый хеш, и sha-256 - отличный алгоритм. Соль должна быть криптографическим одноразовым номером, как в очень случайном значении, которое используется только 1 на хеш.

MySQL, AES_ENCRYPT() отстой, его использование режима ECB, который ужасен. Если вызов функции не имеет IV, то это, вероятно, режим ECB, если IV равен нулю, то это нарушение CWE-329.

Простой текст:

зашифрованы в режиме ECB:

Шифрование затруднительно, вам нужно беспокоиться о векторах инициализации, режимах работы, хранении ключей и функциях string2key. Подавляющее большинство программистов думают, что криптография проста, но им удается серьезно испортить ситуацию Получить копию практической криптографии, прямо к делу и не тяжело математике. Если вам нравится математика, тогда переходите к "Справочнику".

РЕДАКТИРОВАТЬ: Мне не очень нравится ваше nonce поколение, потому что оно имеет плохое соотношение энтропии / размера. Соль base16 - это пустая трата, когда у вас может быть соль 256 base. Имейте в виду, что большинство (вероятно, все) реализации дайджеста сообщений безопасны в двоичном формате. Также uniqid() использует много времени в своих расчетах, и если бы он использовал только время, это было бы нарушением CWE-337. Теперь с другой стороны mt_rand() пинает задницу. Также имейте в виду, что вы, вероятно, должны сохранить это как base64, а затем декодировать base64 перед использованием в вашей хэш-функции.

    public function nonce($size=32){//256 bit == 32byte. 
        for($x=0;$x<$size;$x++){
            $ret.=chr(mt_rand(0,255));
        }
        return base64_encode($ret);
    }