szukaj

08.05.2017 | 07:03

avatar

krystian

Bezpieczna kopia zapasowa za pomocą kryptografii asymetrycznej

Użytkownicy komputerów podobno dzielą się na tych, którzy już robią backupy i tych, którzy zaczną je robić jak tylko stracą swoje dane. My mamy nadzieje, że nasi Czytelnicy dzielą się na tych, którzy robią backupy i tych, którzy także je szyfrują.

W sieci nie brakuje usług tworzenia kopii bezpieczeństwa w chmurze. Znaleźć można także dostawców, którzy oferują również szyfrowanie przechowywanych danych. Można też uruchomić gotowe rozwiązania do tworzenia kopii bezpieczeństwa na własnych lokalnych lub zdalnych serwerach. Naszym zdaniem warto jednak czasem zrobić coś samodzielnie i od początku do końca, by przy okazji nauczyć się czegoś nowego. Dlatego też dzisiaj przypomnimy podstawy kryptografii asymetrycznej oraz wykorzystamy ją do stworzenia bezpiecznych, zaszyfrowanych kopii bezpieczeństwa na zdalnym serwerze.

Artykuł pod patronatem Aruba Cloud

We współpracy z firmą ArubaCloud pokazaliśmy Wam, jak postawić swój serwer backupów, jak skonfigurować własny serwer VPN i podłączyć do niego komputer, telefony komórkowe oraz domowy ruter a także jak schować się przed cenzurą sieci i jak zacząć serwer zabezpieczać, jak postawić swój własny zdalny pulpitswój serwer WWWjak monitorować zmiany w plikach oraz jak zablokować reklamy na komórce.

Jeśli nie macie jeszcze swojego własnego serwera, to jest to dobra okazja by się w taki wyposażyć. Aruba oferuje dwa miesiące korzystania ze swojego podstawowego serwera gratis – a po zakończeniu promocji będzie on Was kosztował zaledwie 4 złote miesięcznie. Instrukcję jak krok po kroku skorzystać z promocji i uruchomić swój serwer znajdziecie w tym artykule. Jeśli macie już swój serwer – to zapraszamy do lektury kolejnych akapitów.

Cały proces konfiguracji serwera możecie obejrzeć na poniższym filmie. Pod nim znajdziecie szczegółowy opis tekstowy.

Kliknij tutaj, aby wyświetlić treść z YouTube.
Dowiedz się więcej w polityce prywatności.

Kryptografia asymetryczna

Na początek szczypta teorii. W kryptografii asymetrycznej wyróżniamy dwa pojęcia:

  • Klucz prywatny
    Klucz ten służy do odszyfrowywania oraz podpisywania danych. Posiadając klucz prywatny możemy uwierzytelnić naszą tożsamość. Klucza prywatnego nikomu nie wysyłamy – nie udostępniamy go osobom trzecim, nie udostępniamy go również w internecie. Jak sama nazwa wskazuje – jest to klucz prywatny. Podglądając zawartość pliku z kluczem prywatnym warto zwrócić uwagę, że plik ten rozpoczyna się linią „BEGIN PGP (lub RSA) PRIVATE KEY BLOCK”. Utrata klucza uniemożliwia nam odszyfrowanie danych – sami musimy zadbać o jego bezpieczne przechowywanie.
  • Klucz publiczny
    Jak sama nazwa wskazuje – klucz ten może być udostępniany osobom trzecim. Klucz publiczny służy do szyfrowania danych. Jeśli nadawca chce zaszyfrować dane przesyłane do właściciela klucza, korzysta wyłącznie z klucza publicznego. Zawartość pliku publicznego rozpoczyna się linią „BEGIN PGP PUBLIC KEY BLOCK”

W artykule wygenerujemy dwie pary kluczy:

  • Klucz publiczny i prywatny do uwierzytelnienia przez SSH. Ta para kluczy będzie wykorzystywana do łączenia się do zdalnego serwera kopii zapasowych przez protokół SSH bez konieczności wpisywania hasła.
  • Klucz publiczny i prywatny PGP do szyfrowania danych. Klucze te będą wykorzystywane do szyfrowania i odszyfrowania plików, które znajdują są na serwerze kopii zapasowej.

Wygenerowane klucze wykorzystują kryptografię asymetryczną.

Nasz plan działania:

  • utworzymy klucze do autoryzacji SSH,
  • wgramy klucz publiczny na serwer zdalny aby uwierzytelnić się za pomocą kluczy,
  • utworzymy parę kluczy PGP,
  • zaszyfrujemy przykładowe dane,
  • zsynchronizujemy katalog lokalny z katalogiem zdalnym.

Klucze SSH

Na komputerze lokalnym generujemy parę kluczy do autoryzacji za pomocą protokołu SSH. Klucz prywatny zostawiamy na komputerze/serwerze, z którego będziemy przesyłali dane na serwer zdalny.

$ ssh-keygen -t rsa -b 4096 -C "twoj_adres@email"
Generating public/private rsa key pair.
Enter file in which to save the key (/home/krystian/.ssh/id_rsa): - enter
Enter passphrase (empty for no passphrase): - czy klucz prywatny powinien być zabezpieczony hasłem? - enter
Enter same passphrase again: - enter
Your identification has been saved in /home/krystian/.ssh/id_rsa.
Your public key has been saved in /home/krystian/.ssh/id_rsapub.
The key fingerprint is:
fe:86:9c:5b:63:87:23:e4:a6:b2:b7:26:12:3a:79:ba twoj_adres@email
The key's randomart image is:
+--[ RSA 4096]----+
|                 |
|                 |
|                 |
|                 |
|        S        |
|  .    +   .     |
| o .   .=o* .    |
|+ o o oo+=.+     |
|E= ..*o..o.      |
+-----------------+

Poleceniem 'ssh-keygen’ utworzyliśmy parę kluczy RSA. Klucz prywatny został zapisany do pliku /home/krystian/.ssh/id_rsa, natomiast klucz publiczny – /home/krystian/.ssh/id_rsa.pub.

Klucz publiczny (id_rsa.pub) wgrywamy na serwer kopii bezpieczeństwa. Wgranie klucza publicznego umożliwi nam logowanie się do konta bez potrzeby podawania hasła.

Zanim wgramy klucz publiczny na serwer kopii zapasowej, utwórzmy na nim konto, na które będziemy logowali się bez podawania hasła – na przykład konto o nazwie „backup”

$ ssh root@aruba-cloud
# adduser backup
# passwd backup - tymczasowo ustawiamy hasło do konta by wgrac klucz publiczny
# chmod 700 /home/backup - ustawiamy odpowiednie uprawnienia do katalogu /home/backup

Mając utworzone konto o nazwie 'backup’ na serwerze zdalnym, możemy wgrać klucz publiczny by logować się na konto bez podawania hasła

$ ssh-copy-id -i /home/krystian/.ssh/id_rsa.pub backup@aruba-cloud
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
backup@aruba-cloud password:

Number of key(s) added: 1

Now try logging into the machine, with: "ssh 'backup@aruba-cloud'"
and check to make sure that only the key(s) you wanted were added.

Po wgraniu klucza sprawdzamy, czy możemy zalogować się do konta za jego pomocą:

$ ssh backup@aruba-cloud
Last login: Fri Apr 28 11:44:07 2017

[backup@aruba-cloud ~] $

Tym oto sposobem uzyskaliśmy autoryzację za pomocą pary kluczy RSA do logowania się na konto o loginie „backup” na serwerze zdalnym. Logujemy się po raz drugi na serwer w Aruba Cloud jako root i blokujemy hasło dla użytkownika 'backup’:

$ ssh root@aruba-cloud
# passwd -l backup

Klucze PGP

Na komputerze lokalnym utworzymy parę kluczy PGP którymi będziemy szyfrować/odszyfrowywać pliki.

Generujemy klucz publiczny oraz klucz prywatny o długości 4096 bitów – pod koniec generowania klucza będziemy poproszeni o podanie hasła w celu zabezpieczenia klucza prywatnego:

$ gpg2 --gen-key
gpg (GnuPG) 2.0.22; Copyright (C) 2013 Free Software Foundation, Inc.

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Please select what kind of key you want:
(1) RSA and RSA (default)
(2) DSA and Elgamal
(3) DSA (sign only)
(4) RSA (sign only)
Your selection?
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 4096
Requested keysize is 4096 bits
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0) 0
Key does not expire at all
Is this correct? (y/N) y

GnuPG needs to construct a user ID to identify your key.

Real name: Krystian
Email address: twoj_adres@email
Comment:
You selected this USER-ID:
"Krystian <twoj_adres@email>"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O
You need a Passphrase to protect your secret key.

gpg: /home/krystian/.gnupg/trustdb.gpg: trustdb created
gpg: key E53476EB marked as ultimately trusted
public and secret key created and signed.

gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u
pub 4096R/BF189AE0 2017-04-29
 Key fingerprint = 8B02 0C56 75AF F0F9 A1A7 C78E C03A 3F11 BF18 9AE0
uid Krystian <twoj_adres@email>
sub 4096R/9EB2A3AF 2017-04-29

Utworzyliśmy klucz główny od identyfikatorze BF189AE0 oraz podklucz o identyfikatorze 9EB2A3AF do szyfrowania danych i plików.

Szyfrujemy pliki i wysyłamy na serwer

Tworzymy dwa katalogi: /tmp/pliki/zaszyfrowane oraz /tmp/pliki/niezaszyfrowane w którym utworzymy plik dane.txt:

$ mkdir -p /tmp/pliki/{zaszyfrowane,niezaszyfrowane}
$ echo "Dane testowe" > /tmp/pliki/niezaszyfrowane/dane.txt

Następnie zaszyfrujemy plik dane.txt naszym kluczem PGP – zaszyfrowany plik zapiszemy do katalogu /tmp/pliki/zaszyfrowane jako dane.txt.pgp:

$ gpg --encrypt --output /tmp/pliki/zaszyfrowane/dane.txt.pgp --recipient twoj_adres@email /tmp/pliki/niezaszyfrowane/dane.txt

Po wykonaniu powyższej komendy został utworzony plik dane.txt.gpg:

$ file /tmp/pliki/zaszyfrowane/dane.txt.gpg
dane.txt.gpg: GPG encrypted data

$ ls -la /tmp/pliki/zaszyfrowane/dane.txt.gpg
-rw-r--r-- 1 root root 608 Apr 26 20:40 dane.txt.gpg

Aby wgrać go na zdalny serwer instalujemy pakiet 'rsync’.

$ sudo yum install rsync -y

Po instalacji pakietu wgrywamy zawartość katalogu /tmp/pliki/zaszyfrowane na zdalny serwer:

$ rsync -avz -e "ssh" --progress /tmp/pliki/zaszyfrowane/ backup@aruba-cloud:/home/backup/

sending incremental file list
./
dane.txt.gpg
 608 100% 0.00kB/s 0:00:00 (xfer#1, to-check=0/2)

sent 706 bytes received 34 bytes 296.00 bytes/sec
total size is 608 speedup is 0.82

Rsync idealnie nadaje się do synchronizacji wielu plików oraz katalogów – jeśli będziecie chcieli zsynchronizować katalog lokalny z katalogiem zdalnym – jest to narzędzie którym warto się posłużyć.

Skrypt automatyzujący szyfrowanie

Na potrzeby artykułu utworzyliśmy bardzo prosty skrypt. Skrypt ten pobiera listę plików w zdefiniowanym katalogu, szyfruje je do oddzielnego katalogu, a następnie wysyła je na serwer zdalny.

#!/bin/bash

# adres e-mail właściciela klucza pgp
PGP_ADDRESS="twoj_adres@email"

# katalog w którym przechowywane są niezaszyfrowane pliki
SOURCE_DIR="/tmp/pliki/niezaszyfrowane/*"
# katalog do którego będą wgrywane zaszyfrowane pliki
DESTINATION_DIR="/tmp/pliki/zaszyfrowane"

# adres serwera zdalnego
REMOTE_SERVER=aruba-cloud

# użytkownik na serwerze zdalnym
REMOTE_USER=backup

# pełna scieżka na serwerze zdalnym
REMOTE_DIR="/home/backup/"

# pętla główna - sprawdzamy każdy plik w SOURCE_DIR
for f in ${SOURCE_DIR}
do
    plik=$(basename "$f.gpg")
    echo "Szyfruję plik $f do pliku ${DESTINATION_DIR}/${plik}"
    gpg  --output ${DESTINATION_DIR}/${plik} --encrypt \
	--recipient ${PGP_ADDRESS} $f

    # sprawdzamy czy wystąpił błąd podczas szyfrowania pliku
    if [ $? == 0 ]
    then
	echo -n " Sprawdzam czy istnieje zaszyfrowany plik..."
	# sprawdzamy czy plik istnieje
	if [ -f ${DESTINATION_DIR}/${plik} ]
	then
	    echo " Plik istnieje"
	# jesli plik nie istnieje
	else
	    echo " Błąd! Brak zaszyfrowanego pliku ${DESTINATION_DIR}/${plik}!"
	fi
    # jeśli wystąpi błąd podczas wykonywania polecenia `gpg`
    else
		echo " Bład podczas szyfrowania pliku"
    fi

# koniec petli glownej
done
echo "Przenoszę zaszyfrowane pliki na serwer zdalny"

rsync --dry-run --remove-source-files -avz -e \
	"ssh" --progress \
	${DESTINATION_DIR} \
	${REMOTE_USER}@${REMOTE_SERVER}:${REMOTE_DIR}

W zmiennej SOURCE_DIR zdefiniowano katalog, gdzie znajdują się pliki gotowe szyfrowania. Zaszyfrowane pliki będą zapisywane do katalogu zdefiniowanego w zmiennej DESTINATION_DIR. Ostatnim etapem jest przeniesienie plików na zdalny serwer. Dla bezpieczeństwa w poleceniu rsync użyto argumentu –dry-run – użycie tego argumentu powoduje, że narzędzie rsync zostanie uruchomione bez faktycznego wprowadzania zmian na dysku.

Nadajemy odpowiednie uprawnienia dla pliku:

$ chmod 700 autobackup.sh

Usuwamy plik 'dane.txt.gpg’ z katalogu /tmp/pliki/zaszyfrowane oraz uruchamiamy plik autobackup.sh:

$ rm /tmp/pliki/zaszyfrowane/dane.txt.gpg
$ ./autobackup.sh 
Szyfruje plik /tmp/pliki/niezaszyfrowane/dane.txt do pliku /tmp/pliki/zaszyfrowane/dane.txt.gpg
 Sprawdzam czy istnieje zaszyfrowany plik... Plik istnieje
Przenoszę zaszyfrowane pliki na serwer zdalny
sending incremental file list
zaszyfrowane/
zaszyfrowane/dane.txt.gpg

sent 97 bytes  received 19 bytes  77.33 bytes/sec
total size is 608  speedup is 5.24 (DRY RUN)

sent 121 bytes  received 22 bytes  95.33 bytes/sec
total size is 33569969  speedup is 234755.03 (DRY RUN)

Zadanie cykliczne

Ustawiamy nasz ulubiony edytor tekstu:

export EDITOR=nano
export VISUAL=nano

oraz edytujemy crontab by uruchamiał skrypt autobackup.sh codziennie o pierwszej godzinie w nocy:

$ crontab -e

0 1 * * * /home/krystian/autobackup.sh

Podsumowanie

Celem artykułu było wytłumaczenie na czym idei klucza publicznego i klucza prywatnego oraz pokazanie ich praktycznego zastosowania do tworzenia bezpiecznych kopii zapasowych. Mamy nadzieję, że już szyfrujecie swoje backupy. Bo robicie je regularnie, prawda? :)

Dla pełnej przejrzystości – za przygotowanie oraz opublikowanie powyższego artykułu otrzymujemy wynagrodzenie.

Powrót

Komentarze

  • avatar
    2017.05.08 09:55 Tomasz Klim

    Jeśli mogę się wtrącić z kryptoreklamą – znacznie pewniejszym rozwiązaniem od ręcznego dziergania będzie użycie jakiegoś gotowego rozwiązania.

    Np. framework Server Farmer automatyzuje cały proces szyfrowanego backupu serwera, począwszy od w pełni automatycznego wykrycia, jakie katalogi i inne zasoby (np. bazy danych) na danym serwerze wymagają zabezpieczenia, poprzez ich zaszyfrowanie GPG i zaciąganie do ustalonej lokalizacji.

    Różnica pomiędzy SF a rozwiązaniem opisanym wyżej jest przy tym taka, że to serwer backupu inicjuje kopiowanie z serwerów „podległych”. Dzięki temu jeśli ktoś się nam włamie na jeden z takich serwerów, nie będzie w stanie skasować backupów, jak to miało miejsce np. rok temu w 2BE.pl.

    Jeśli ktoś będzie zainteresowany stworzeniem gotowego profilu dla Aruby, aby zainstalować całe rozwiązanie jednym poleceniem – zapraszam do kontaktu, chętnie pomogę.

    Więcej informacji:

    http://serverfarmer.org/
    https://github.com/serverfarmer

    Odpowiedz
    • avatar
      2017.05.12 18:48 adamu

      Cały myk polega na tym aby nie używać gotowych rozwiązań i świadomie wiedzieć co się dzieje z naszymi danymi

      Odpowiedz
  • avatar
    2017.05.08 10:31 SWilk

    A żeby to wszystko zrobić znacznie wygodniej możemy użyć Duplicati.

    Odpowiedz
  • avatar
    2017.05.08 11:42 pm

    Polecam zobaczyć narzędzie „duplicity”.
    http://duplicity.nongnu.org/features.html
    Robi automatycznie wszystko to, co w artykule (poza oczywiście generowanie kluczy ssh i gpg), ma dużo dodatkowych funkcji, dobrze sobie radzi z oszczędzaniem miejsca dzięki backupom różnicowym.

    Odpowiedz
  • avatar
    2017.05.08 11:54 Ojcowianin

    Trochę lokowanie produktu..

    Odpowiedz
  • avatar
    2017.05.08 11:59 v

    Ja bym z tego skryptu nie korzystał. Nic w nim nie jest zabezpieczone przed word splittingiem. A z tego co wiem to nazwy plików mogą i często nawet zawierają spacje…

    Odpowiedz
  • avatar
    2017.05.08 12:08 Wojtek

    Mam jedno pytanie:

    Co w razie awarii dysku kompa lokalnego / straty kompa / umycia przez dziecko w wannie i wsłania w kosmos klucza prywatnego PGP?

    Odpowiedz
    • avatar
      2017.05.08 23:20 Marek

      Klucze prywatne też się backupuje. Np. na smart card trzymany w sejfie, ale to chyba temat na oddzielny artykuł.

      Odpowiedz
    • avatar
      2017.05.09 15:24 Krzysztof Kozłowski

      Jak to co? Przecież masz zaszyfrowaną kopię w backupie…. ;)

      Odpowiedz
  • avatar
    2017.05.08 13:28 mikołaj

    Warto pamiętać i podkreślić backupu kluczy. Jeśli nie ma backupu kluczy to tak jakby backupu nie było, bo i tak nie rozszyfrujemy backupu.

    Odpowiedz
  • avatar
    2017.05.08 13:38 Marcin

    PGP nie szyfruje danych kluczem asymetrycznym.

    Działa to mniej więcej tak:
    1. Tworzony jest klucz sesyjny (duża liczba losowa).
    2. Dane są szyfrowane symetrycznie za pomocą klucza sesyjnego (np. AES).
    3. Klucz sesyjny jest szyfrowany kluczami publicznymi odbiorców i jest doklejany do danych (kryptografia asymetryczna).

    Odszyfrowywanie jest odwrotne:
    1. Odbiorca odszyfrowuje klucz sesyjny za pomocą swojego klucza prywatnego (kryptografia asymetryczna).
    2. Dane są odszyfrowywane za pomocą klucza sesyjnego (kryptografia symetryczna).

    Odpowiedz
  • avatar
    2017.05.08 14:06 endetti

    Do tworzenia bezpiecznych kopii polecam BORG Backup – https://github.com/borgbackup/borg#what-is-borgbackup

    Szyfrowanie po stronie klienta, deduplikacja, kompresja, automatyzacja – działają elegancko. BORGa można postawić praktycznie wszędzie. Na Arubie również się sprawdzi. ;)

    Odpowiedz
  • avatar
    2017.05.08 14:19 Wujek Pawel

    No kurde chłopaki mamy dziś ed25519, a wy dalej lansujecie rsa…

    Odpowiedz
  • avatar
    2017.05.08 18:29 MG

    Jeśli mogę trochę skrytykować – szyfrowanie plików nie odbywa się za pomocą szyfrów asymetrycznych. Tak co najwyżej szyfruje się symetryczny klucz sesyjny. Niby dałoby się, ale to obliczeniowo słabo by działało. Za to „certyfikat prywatny” to już chyba jednak nie bardzo w tym kościele.

    Odpowiedz
  • avatar
    2017.05.08 19:05 Przemek

    A nie lepiej skorzystać z narzędzia które wspiera GPG out of the box? Duplicity z nakładką duply jest znacznie prostszy w konfiguracji i wspiera backendy jak AWS lub Azure.

    Odpowiedz
  • avatar
    2017.05.08 20:10 M.

    Szkoda tylko, że nasza infrastruktura nadal nie dorosła do kopii w chmurze. Z łączem 0,45 Mb/s niewiele się zrobi.

    Odpowiedz
  • avatar
    2017.05.08 20:36 arturo

    W ogóle nieskomplikowane…

    Odpowiedz
  • avatar
    2017.05.08 23:36 czesław

    Taki podział tez funkcjonuje:

    Ludzie dzielą sie na takich którzy robią backupy i na tych którzy myślą, że robią.

    Polecam proste rozwiązania np. Ferro Backup, który szyfruje AESem 256 i można replikować na USB lub owncloud jak ktoś lubi backup online. Działa na linuksie (docker).

    Aplikacja płatna.

    Odpowiedz
  • avatar
    2017.05.09 08:37 Sławomir Łata

    Nie wiem czemu się czepiacie, przecież wyraźnie jest zaznaczone, że tekst miał w priorytecie użycie kryptografii asymetrycznej i należy go traktować przede wszystkim jako tekst edukacyjny. Jak ktoś wcześniej nie spotkał się np. z generowaniem kluczy, to z pocałowaniem ręki weźmie taki przykład. Poza tym zamiast backupu można sobie do skryptu wrzucić dowolne wrażliwe dane, np. zdjęcie teściowej. ;)

    Odpowiedz
  • avatar
    2017.05.10 18:21 Konrad

    Dokładnie jak Przemek napisał — tylko duply, który jest wrapperem do duplicity. Działanie, bezawaryjność, konfigurowalność — osom.

    Odpowiedz
  • avatar
    2017.05.11 18:14 S.J.

    Potwierdzam i podtrzymuję opinię przedmówców – jak backup via linuch to tylko duply/duplicity: kładzie niejedno komercyjne rozwiązanie na łopatki…
    ;)

    Odpowiedz
  • avatar
    2017.05.12 03:06 Artur

    A ja mam pytanie – kto rozsadny wrzuca swoje backup’y do roznego rodzaju 'chmur’?

    Przeciez te dane zostana juz tam na zawsze (patrz dropbox – jakie mamy gwarancje ze jak cos usuniemy to bedzie to na prawde usuniete).

    Czy moge rozniez zalozyc ze za kilka lat nasze dane bedzie mozna odszyfrowac jako ze klucze uzyte pierwszy raz beda juz zbyt male?

    Backup – tak. Szyfrowany – tak. Gdzies na sieci – nigdy.

    Pozdr,
    -M.

    Odpowiedz
  • avatar
    2017.05.13 09:53 Rower

    Lepiej w skrypcie dać plik=${f##*/}
    Wtedy nie odpala się kolejny proces przy każdym przejściu pętli.

    Odpowiedz
  • avatar
    2017.05.15 22:36 Robert

    Od jakiegoś czasu korzystam z tarsnap i jestem bardzo zadowolony: pliki są szyfrowane lokalnie, jest dobra deduplikacja a dzięki rozliczeniom w pikodolarach (tak, pikodolarach – to nie jest literówka ;)) niewiele to kosztuje.

    Odpowiedz

Zostaw odpowiedź

Jeśli chcesz zwrócić uwagę na literówkę lub inny błąd techniczny, zapraszamy do formularza kontaktowego. Reagujemy równie szybko.

Bezpieczna kopia zapasowa za pomocą kryptografii asymetrycznej

Komentarze