Tag: safety

Rails + MySQLDump czyli robienie kopii zapasowej bazy danych z poziomu Railsów

Zabezpieczenie systemu jest (jak nie muszę przekonywać) bardzo ważną sprawą. Jedną z podstawowych metod zapewnienia bezpieczeństwa systemu jest regularne wykonywanie kopii zapasowych bazy danych. Wprawdzie w Ruby on Rails nie istnieje ujednolicony interfejs do wykonywania tej czynności, jednak bardzo prosto można napisać własny model wykonujący dumpa.

Model jest bardzo prosty. Jeśli chodzi o migrację to zawiera ona tylko timestampy (created_at, updated_at). Jeśli chodzi o klasę, to jej szkielet wygląda tak:

# coding: utf-8

require 'fileutils'

# Służy do wykonywania kopii zapasowych plików oraz bazy danych
# Działa dla MySQLa - robi dumpa bazy
class Backup < ActiveRecord::Base
  # Zawartość
end

Dalej nie jest trudniej :) Musimy ustalić prefiks dla nazwy pliku, który będzie przechowywał nasz zrzut:

  # Prefix do nazwy backupu bazy danych
  DB_NAME_PREFIX = 'db_'

Oraz nadpisać metodę create, która oprócz utworzenia wpisu w bazie danych, utworzy nam także nasz zrzut.

Aby wykonać zrzut, musimy mieć dostęp do kilku informacji:

  • Nazwa bazy
  • Login
  • Hasło
  • Host
  • Możliwość wykonywania poleceń zewnętrznych
  • Ścieżka do backupu

Tak naprawdę, nie potrzebujemy niczego szczególnego. Zanim jednak przystąpimy do tworzenia naszej metody create, omówmy sobie jeszcze jak ma wyglądać przechowywanie kopii zapasowych.

Proponowałbym utworzyć logiczną hierarchię dla plików i katalogów. W głównym katalogu aplikacji, tworzony będzie katalog backup/. W nim będą subkatalogi, których nazwy składać się będą z daty oraz czasu wykonania kopii. W środku takiego subkatalogu będzie spakowany zrzut bazy.

Idąc za ciosem, zdefiniujmy sobie metodę prywatną, która sprawdzi nam czy katalog backup/ oraz jego subkatalog istnieją. Metoda ta jest na tyle prosta, że nie ma co jej opisywać. Komentarze powinny wystarczyć:

  # Sprawdzamy czy ścieżka gdzie ma być backup istnieje i jeśli nie to ją
  # utworzymy
  # Jako parametr podajemy czas - to jest nazwa folderu jako sygnatura czasowa
  # momentu rozpoczecia backupowania, czas w formacie Time.now.strftime("%Y\-%m\-%d_%H\-%M\-%S")
  def check_path(time)
    # Sprawdzajmy czy struktura katalogow jest cala - od poczatku (wiem że to
    # narzut tych kilku sprawdzen, ale tak jest prościej)
    full_backup_path = "#{Rails.root}/backup/#{time}/"
    check_path = ''
    full_backup_path.split('/').each { |el|
      check_path += "#{el}/"
      Dir.mkdir(check_path) unless File.directory?(check_path)
    }
  end

Mając już metodę, która zapewni nam, że będzie gdzie przechowywać plik ze zrzutem, możemy przystąpić do pisania metody create.

Pierwszą rzeczą jaką musimy zrobić, jest zapamiętanie czasu w którym przystąpiliśmy do tworzenia backupu. Jest to bardzo istotne, ponieważ jeśli operowalibyśmy na Time.now mógłby on różnić się dla subkatalogu oraz nazwy pliku (i ew. wpisu w bazie), co prowadziłoby do wielu problemów. Ominiemy je jednak wykonując na początku metody taki fragment kodu:

  # Nadpisujemy domyślne create żeby wykonywało kopię
  def create
    # Potrzebujemy jeden czas dla plików i dla utworzenia obiektu modelu Backup
    time = Time.now
    super
    self.created_at = time
    self.save
    # Musimy mieć czas w takim formacie aby dało się tym nazwać pliki
    file_time = time.strftime("%Y\-%m\-%d_%H\-%M\-%S")

Zapamiętaliśmy w zmiennej time aktualny czas, zapisaliśmy go także jako wartość created_at dla backupu. Na końcu konwertujemy czas do formatu który będzie stanowił nazwę dla naszego subkatalogu (np 2010-09-20_19-12-56).

Mając już "globalny" czas, możemy sprawdzić (i jeśli trzeba - a trzeba na pewno ;)) i utworzyć strukturę katalogów dla kopii zapasowej. W tym celu wywołamy następujący kod (który napisaliśmy wcześniej):

     # Jeśli nie ma katalogu na backupy to go utwórz
    check_path file_time

Ustalmy teraz jak ma nazywać się plik z kopią zapasową bazy i gdzie ma się znajdować:

    # Ścieżka gdzie ma zapisać plik bazy danych
    backup_db = "#{Rails.root}/backup/#{file_time}/#{DB_NAME_PREFIX}#{file_time}.sql.bz2"

Teraz pozostało nam tylko wyciągnąć parametry dostępowe do bazy oraz wykonać dump:

    db = self.configurations[Rails.env]['database']
    db_user = self.configurations[Rails.env]['username']
    db_pass = self.configurations[Rails.env]['password']
    db_host = self.configurations[Rails.env]['host']

    # Zrzut bazy danych
    exec "mysqldump --add-drop-table -u #{db_user} -p#{db_pass} -h #{db_host} #{db} | bzip2 -c > #{backup_db}" if fork.nil?

Baza po zrzucie zostanie spakowana.

Mamy już kopię zapasową oraz odpowiadający jej model. Musimy jednak zapewnić sobie możliwość usuwania powstałych kopii. Aby tego dokonać nadpiszemy metodę destroy w taki sposób aby usuwając instancję modelu, usuwała także korespondujący katalog z kopią zapasową:

  # Usuwa stary backup oraz zadane pliki do niego
  def destroy
    return if self.new_record?
    dir = "#{Rails.root}/backup/#{self.created_at.strftime("%Y\-%m\-%d_%H\-%M\-%S")}"
    # Usuwamy katalog z backupem
    FileUtils.rm_rf(dir) if File.directory?(dir)
    super
  end

To by było na tyle. Zachęcam Was do utworzenia w analogiczny sposób, kodu odpowiedzialnego za backupowanie plików userów - np katalogu /public/uploads/.

Logi systemowe w Rails a hasła i inne newralgiczne dane

Środowisko Rails przechowuje w logach wiele danych. M.in to co przesyłamy w żądaniach.

Problem pojawia się gdy przesyłamy login i hasło (np. podczas logowania lub rejestracji). Osoba która uzyska dostęp do logów, mogłaby z nich "wyciągnąć" te newralgiczne dane. Aby temu zapobiec, należy "przysłonić" wrzucanie do logów tych pól z formularzy które są niebezpieczne.

Aby to zrobić należy skorzystać z metody:

  filter_parameter_logging

Która po podaniu parametrów usunie je, zanim trafią do loga. Aby w całej naszej aplikacji przysłonić tworzenie logów zawierających hasła wystarczy w kontrolerze aplikacji (ApplicationController) dodać następująca linijkę:

  filter_parameter_logging :password

Dzięki temu, mając jakiekolwiek pola zawierające słowo password, ich zawartość zostanie zamieniona na [FILTERED]. Nie ma to znaczenia czy są w hashu zawierającym hasha:

params[:test][:deeper][:password]
params[:test][:deeper][:password_confirmation]

Czy też "na wierzchu":

params[:password]
params[:password_confirmation]

W każdym z tych przypadków, hasła nie zostaną zapisane w logach.

Copyright © 2024 Closer to Code

Theme by Anders NorenUp ↑