Excel izpostavlja dve stvari, ki se obe imenujeta "geslo", in samo ena od njiju je šifriranje. Geslo za odpiranje krmili pravo šifro: brez njega datoteke sploh ni mogoče prebrati. Gesla za zaščito delovnih listov in delovnih zvezkov tega ne počnejo. Nastavijo zastavico, ki jo sodelujoči urejevalnik privoli spoštovati, in delovni zvezek, ki nosi samo to zastavico, je navaden berljiv zip s podatki v jasnem besedilu. Izberite napačno in dostavite plačilno listo, ki je videti zaklenjena v Excelu, a se bere v katerem koli urejevalniku besedil.
Dokaz traja deset sekund. Preimenujte zaščiteni .xlsx v .zip, ga odprite v katerem koli orodju za arhiviranje in poglejte xl/worksheets/sheet1.xml. Če so vrednosti celic tam v jasnem UTF-8, datoteka ni šifrirana, ne glede na to, koliko pozivov za geslo Excel prikaže, ko kdo poskuša urediti celico. Ta vrzel preživi leta v ekipah, ki predpostavljajo, da je zaščita lista enaka zaupnosti, in navadno pride na dan, ko varnostni pregled izvede točno to preimenovanje.
HotXLS je izvorna knjižnica preglednic za Delphi in C++Builder, ki obe funkciji ohranja na nasprotnih straneh te meje. Zaščita delovnega lista in delovnega zvezka sta omejitvii urejanja, ki ju podpira namenoma šibka zastarela zgoščevalna funkcija. SaveAsEncrypted ustvari AES-šifrirani paket, ki ga brez gesla ni mogoče odpreti. Spodnji razdelki pokrivajo, kaj ta klic zapiše, asimetrijo, ki jo je treba upoštevati pri zasnovi (HotXLS piše šifrirane datoteke, a jih ne more brati nazaj), in kako se starejša pot XLS razlikuje.
Zakaj zaščita lista ni šifriranje
Metode Protect na listih in ProtectWorkbook na delovnem zvezku shranjujejo 4-heksadecimalno zgoščevano vrednost gesla. To je zastareli algoritem, ki sta ga OOXML in BIFF oba podedovala od Excela iz devetdesetih let, in dokumentacija formata nikoli ne trdi, da počne več kot preprečuje naključna urejanja. Paket ostane navaden berljiv zip: podatki celic, formule in skupni nizi so vsi v jasnem besedilu XML. Privzeta vrednost stvar poslabša in ne izboljša. Vsaka celica se začne z Locked=True, zato klicanje Protect brez predhodnega odklepanja vnosnega obsega zamrzne celoten list pred urejanjem, hkrati pa pusti vsako vrednost na vidiku.
Kar ne naredi zaščite neuporabne. Usmerjanje uporabnikov v urejalne obsege in stabilizacija postavitve za tiskanje sta resnični nalogi, pokrita v našem članku o zaščiti delovnih listov in nastavitvi strani. Toda to so nalogi za uporabnost. V trenutku, ko je zahteva zaupnost, je edini API, ki jo zadovolji, SaveAsEncrypted.
Kaj SaveAsEncrypted dejansko zapiše
Implementacija sledi standardnemu šifriranju ECMA-376, navedenemu v [MS-OFFCRYPTO] razdelek 2.3.4. Geslo se izvaja skozi 50.000 iteracij SHA-1 za izpeljavo ključa AES-128. Blok za preverjanje, šifriran z AES-128 v načinu ECB, potrošniku omogoča potrditev gesla, preden karkoli dešifrira, nato pa je celoten paket delovnega zvezka šifriran z AES-128 v načinu CBC. Kar pristane na disku, sploh ni zip. To je datoteka OLE z vsebovalci toka EncryptionInfo, EncryptedPackage in DataSpaces, brez imenika xl/ za orodja arhiviranja, kar je razlog, da preimenovalni test zdaj ne pokaže ničesar berljivega. Excel 2007 in novejši jo odpre samo z geslom, trenutni LibreOffice pa prav tako bere standardno šifriranje.
var
Book: TXLSXWorkbook;
Sheet: TXLSXWorksheet;
rc: Integer;
begin
Book := TXLSXWorkbook.Create;
try
Sheet := Book.Sheets.Add('Payroll');
Sheet.Cells[1, 1].Value := 'Employee';
Sheet.Cells[1, 2].Value := 'Net pay';
Sheet.Cells[2, 1].Value := 'A. Garcia';
Sheet.Cells[2, 2].Value := 4815.16;
rc := Book.SaveAsEncrypted('payroll-2026-06.xlsx', PasswordFromVault);
if rc <> 1 then
raise Exception.CreateFmt('Encrypted save failed (rc=%d)', [rc]);
finally
Book.Free;
end;
end;
Spremenljivko z geslom obravnavajte z enako skrbnostjo kot niz za povezavo. Pridobite jo iz trezorja ali storitve z generiranimi skrivnostmi ob zadnjem trenutku, je nikoli ne beležite in je nikoli ne zapišite v sam delovni zvezek. Preverjanje kode vrnjene vrednosti ni neobvezna ceremonija. Šifriranje, ki delno ne uspe, mora prekiniti dostavo, ker je edina alternativa, ki jo klicna koda lahko ponudi, nešifrirana kopija, in ta kopija je točno incident, ki mu ta funkcija preprečuje nastati.
Obstaja tudi strojno preverljiv sprejemni test, ki skoraj nič ne stane: pokličite CanReadEncrypted na datoteki, ki ste jo pravkar zapisali. Vrne true samo, ko je izhod resnično vsebnik šifriranja, zato ga preverjanje po vsakem šifriranem shranjevanju ujame najpomembnejšo regresijo, kodno pot, ki je tiho padla nazaj na navaden SaveAs, v trenutku, ko se to zgodi in ne tedne pozneje v poštnem predalu stranke. Končna beseda še vedno pripada ročnemu odpiranju v Excelu z resničnim geslom med testiranjem za izdajo.
Samo za pisanje po zasnovi: ravnanje z EXlsxEncryptionNotImplemented
Tukaj je asimetrija, ki bi morala oblikovati arhitekturo vašega cevovoda: HotXLS šifrira pri shranjevanju, toda ne dešifrira pri odpiranju. OpenEncrypted sproži EXlsxEncryptionNotImplemented, ko je usmerjen na dejanski šifrirani paket; na navadnem delovnem zvezku preprosto pade skozi na navaden Open. Spremljajoča sonda CanReadEncrypted poceni zazna vsebnik šifriranja OLE, zato vhodna koda lahko usmeri takšne datoteke brez sprožitve izjeme:
var
Book: TXLSXWorkbook;
begin
Book := TXLSXWorkbook.Create;
try
if Book.CanReadEncrypted(FileName) then
begin
// Encrypted container: HotXLS cannot decrypt it.
Writeln(FileName + ': needs manual decryption in Excel first');
Exit;
end;
try
Book.OpenEncrypted(FileName, ''); // plain files fall through to Open
Writeln(FileName + ': opened, ' + IntToStr(Book.Sheets.Count) + ' sheet(s)');
except
on EXlsxEncryptionNotImplemented do
Writeln(FileName + ': encrypted - routed to manual queue');
end;
finally
Book.Free;
end;
end;
Ta asimetrija ima en jasen arhitekturni pomen: šifrirajte na robu dostave, zadnji. Ohranite besedilno predlogo v okviru zaupanja, v bazi podatkov, shrambi dokumentov ali deljenem področju z nadzorovanim dostopom, in šifrirano kopijo ustvarite kot zadnji korak, preden datoteka zapusti sistem. Cevovod, ki arhivira le šifrirani izhod, se je zaklenil iz lastnih podatkov, ker nobena kasnejša stopnja istega sistema ne more znova odpreti teh datotek. Ko postopek HotXLS dolvodni ponovno potrebuje delovni zvezek, mu posredujte tekstovnega prednika in ne artefakta dostave.
AES-128 standardno šifriranje in meja skladnosti AES-256
Šifriranje Officeve datoteke prihaja v dveh generacijah. Standardno šifriranje, tisto, ki ga HotXLS piše, uporablja AES-128 z izpeljavo ključa SHA-1. Agilno šifriranje je prispelo pozneje in se premakne na AES-256 s SHA-512 in drugačnim, v XML opisanim vsebnikom ključev. Oba se odpreta brez težav v Excelu, in AES-128 je še vedno računsko trden za zaščito datoteke pri prenosu do stranke.
Razlika preneha biti akademska, ko varnostni vprašalnik zahteva "šifriranje AES-256 datotek v mirovanju." Standardno šifriranje te meje ne zadovolji, ne glede na to, kako močno je geslo, in noben parameter SaveAsEncrypted ne spremeni algoritma, ki ga oddaja. Zato profil navajajte natančno v varnostni dokumentaciji: AES-128, standardno šifriranje ECMA-376, izpeljava ključa SHA-1 pri 50.000 iteracijah. Trditev, ki preživi pregled, je vredna več kot optimistična, ki se sesede pod revizijo.
Zastarela pot XLS: RC4 ven, RC4 in XOR nazaj
Fasada BIFF ima nasprotno obliko. Njeno šifriranje je starejše in šibkejše, a zaokrožno potovanje je popolno: kar zapiše, tudi prebere nazaj. Nastavitev EncryptionPassword pred SaveAs prek mehanizma BIFF FilePass ustvari RC4-šifrirani .xls, in Open z geslom kot parametrom prebere vse tri zastarele sheme, RC4, RC4 CryptoAPI in staro XOR zamedlitev:
var
Writer, Reader: IXLSWorkbook; // interface refs: no manual Free
begin
Writer := TXLSWorkbook.Create;
Writer.Sheets.Add.Cells.Item[1, 1].Value := 'Confidential';
Writer.EncryptionPassword := 'S3cret!';
Writer.SaveAs('confidential.xls');
Reader := TXLSWorkbook.Create;
if Reader.Open('confidential.xls', 'S3cret!') > 0 then
Writeln(Reader.Sheets[1].Cells.Item[1, 1].Value); // Entries are 1-based
end;
RC4 je zastarela kriptografija in ne sme nikoli zaščititi podatkov, ki so danes pomembni; njegova edina preostala vrednost je interoperabilnost s sistemi, ki si še vedno izmenjujejo .xls. Stran branja pa se vrne v migracijskem delu. Geslo-zaščitena zastarela datoteka se odpre z Open(FileName, Password), premosti v model OOXML in znova zavaruje prek poti AES, enosmerna nadgradnja, ki teče brez Excela kjer koli v zanki. Za visokovolumne šifrirane dostave se opombe o pretoku na strani shranjevanja v našem članku o pretočnih pisanjih za paketna opravila na strežniku nanašajo na fazo gradnje vsebine, ki se zgodi pred šifriranjem.
Šifriranje in zaščita nista tekmeca
Ena točka je vredna razjasnitve, ker se pojavi v trenutku, ko kdo prebere opozorilo na vrhu te strani kot "zaščita je neuporabna." Ni. Šifriranje in zaščita odgovarjata na različna vprašanja in se čisto seštevata. Šifriranje odloča, kdo lahko odpre datoteko; zaščita odloča, kaj bralec, ki je že znotraj, sme spremeniti. Dostava plačilne liste lahko razumno naredi oboje: šifrira paket, tako da samo imetnik gesla vidi vsebino, nato zaklene celice s formulami, da prejemnik lahko filtrira in razvršča, a ne more tiho prepisati izračunov. Napaka ni nikoli dodajanje zaščite. Napaka je, da je njena prisotnost nadomestek za šifriranje, ko je zahteva zaupnost.
Stran skrbništva nima varnostne mreže, in to je po zasnovi. 50.000-iteracijska izpeljava ključa obstaja, da drago naredi ugibanje, in nič znotraj datoteke ne hrani skrivnosti. Izgubljeno geslo je izgubiti podatke. Generiranje, dostavljanje in hranjenje teh gesel z enako disciplino, kot jo namenjate poverilnicam baze podatkov, vzdrži šifriranje na svoji strani pogodbe.
Resnično šifriranje datotek je v HotXLS en klic. Disciplina živi v vsem okoli klica: skrbništvo gesel, meja samo za pisanje, ki preprečuje HotXLS, da bi znova odprl lastni izhod, in trditev algoritma, ki jo znate zagovarjati pri reviziji. SaveAsEncrypted in zastarelo zaokrožno potovanje sta priložena z HotXLS Component, ki deluje izvorno v procesih Delphi in C++Builder brez avtomatizacije Excela kjer koli v poti.