# IT-hädaolukord: tellige veebiserverile teenusepakkuja kohe

> IT-hädaolukord veebiserveris? Oleme teenusepakkuja, kes sekkub kaugteel, kindlustab jäljed ja puhastab. Helistage või kirjutage meile WhatsAppis.

Allikas: https://phpsos.de/et/soforthilfe/it-notfall-dienstleister/  
Seis: 25.10.2026  
Pakkuja: PHP SOS, PHP hädaabi ja serveri turvalisus. Kohene abi WhatsAppis: https://wa.me/491736494914?text=Tere%2C%20PHP%20SOS%2C%20vajame%20abi%20oma%20PHP-serveriga.%20Ettev%C3%B5te%3A%20%E2%80%A6%20Veebisait%3A%20%E2%80%A6

**Lühidalt:** Kas see puudutab teid? Helistage. Me aitame. Kui teil on veebiserveris IT-hädaolukord ja eksperti pole käepärast, tellite meid ühe sõnumiga: võtame töö üle esimesest sõnumist, töötame kaugteel ilma kohale sõitmata ja paneme kõik kirja, kuni juhtum on lõpetatud ja dokumenteeritud.

> **Tegutsege kohe:**
> **Ärge praegu midagi kustutage ega installige uuesti.** Ka mitte teenusepakkuja ettevalmistuseks. Süsteemi seis on kõige olulisem tõend. [Teatage hädaolukorrast](https://phpsos.de/et/notfall/), ja selgitame ligipääsud ja rollid koos.

## Kas see puudutab teid? Millal on hädaolukorra teenusepakkuja vajalik

Mitte iga tõrge ei ole turvaintsident. Hädaolukorra teenusepakkuja on mõistlik, kui kehtib vähemalt üks neist punktidest:

- Teie veebiserver käitub silmatorkavalt ja keegi majas ei oska põhjust hinnata.
- On kahtlus kahjuliku koodi, sissemurdmise või lekkinud andmete suhtes.
- Majutaja on teenuse blokeerinud või nõuab puhastamist.
- Teie PHP versioon on vana või selgusetu ja te ei tea, kas PHP2Shelli turvaauke on ära kasutatud.
- Oma IT või agentuur ei ole kättesaadav või puudub neil juhtumite kogemus.

Kahtlusest piisab. Kas saate ise edasi või vajate tuge, aitab kaaluda leht [Ise parandada või kutsuda teenusepakkuja?](https://phpsos.de/et/blog/selbst-beheben-oder-dienstleister/).

## Mida teha kohe

1. **Külmutage seis.** Ei mingeid muudatusi serveris, ei koristusi, ei uuendusi pimesi.
2. **Loetlege ligipääsud.** Millised haldusliidese-, SSH-, CMS- ja andmebaasiligipääsud on olemas ja kes neid haldab?
3. **Teavitage majutajat.** Paluge tal logid ja hetktõmmised (snapshot) säilitada. Ärge jätke ütlemata midagi, mida ta peab teadma.
4. **Määrake otsustaja.** Kes ettevõttes annab loa väljalülitamiseks, taaskäivitusteks ja paroolivahetuseks?
5. **Selgitage andmeseis.** Kas süsteemis on isikuandmeid, makseandmeid või ärisaladusi?
6. **Teavitage osalisi.** Andmekaitsespetsialisti ja, kui on olemas, küberkindlustajat.
7. **Tellige teenusepakkuja.** Helistage või kirjutage WhatsAppis. Võtame töö üle esimesest sõnumist.

## Nii kulgeb tellimine

Hädaolukord ei talu pikka lepingumenetlust, kuid ei talu ka lünki vastutuses ja andmekaitses. Seetõttu tegutseme selles järjekorras:

1. **Esimene vestlus:** Kuulame olukorra ära ja esitame vähesed küsimused, mis on vajalikud esialgse hinnangu jaoks.
2. **Raamistiku kokkulepe:** Selgitame koos, milliseid süsteeme tohime kontrollida, kes otsustab ja kuidas suhtleme.
3. **Andmekaitse korraldamine:** Kui pääseme ligi süsteemidele, kus on isikuandmeid, arutame vajaliku andmetöötluse kokkuleppe. Põhitõdesid selgitab leht [Andmetöötlus serverile ligipääsul](https://phpsos.de/et/blog/auftragsverarbeitung-serverzugriff/).
4. **Ligipääsu seadistamine:** Annate meile ainult need õigused, mis on tööks vajalikud. Pärast lõppu ligipääsud eemaldatakse.
5. **Töö ja aruanded:** Anname vahepealsest seisust teada ja paneme tulemused kirja.

Kuidas pakkujaid üldiselt võrrelda, leiate artiklist [IT-turvalisuse teenusepakkuja valimine: 12 küsimust](https://phpsos.de/et/blog/sicherheitsdienstleister-auswaehlen/). Turvalisusega seotud lepingulisi kohustusi käsitleb [Teenusepakkuja lepingud: turvakohustused selgelt kokku leppida](https://phpsos.de/et/blog/dienstleistervertrag-sicherheit/).

## Kuidas PHP SOS konkreetselt aitab?

1. **Olukorra kaardistamine:** Mis juhtus, millised serverid töötavad, millised PHP versioonid ja töörežiim (PHP-FPM, mod_php, LiteSpeed) on kasutusel?
2. **Kindlustamine ja sulgemine:** Kindlustame logid, failid ja andmebaasi. Seejärel kõrvaldame põhjuse: paik, seadistus või ligipääsude blokeerimine, kõigi PHP protsesside taaskäivitusega.
3. **Kontroll ja puhastamine:** Otsime veebishelle, tagauksi, cron-töid ja võõraid ligipääse ning eemaldame need või ehitame uuesti üles puhastest allikatest.
4. **Karastamine ja aruandlus:** Saate aruande ajajoone, leidude ja soovitustega. Suuremate juhtumite puhul liigume üle [intsidendile reageerimisele (Incident Response)](https://phpsos.de/et/leistungen/incident-response/).

Kui tegemist on alguses ainult PHP turvaauku ja paiga tõendiga, sobib [PHP2Shelli kiirabi ettevõtetele](https://phpsos.de/et/leistungen/php2shell-soforthilfe/). Kui kahjulik kood on olemas, on õige lähtepunkt [pahavara eemaldamine](https://phpsos.de/et/leistungen/malware-entfernung/).

## Mille järgi tunda ära tõsiseltvõetav hädaolukorra teenusepakkuja

Hädaolukorras haaravad paljud esimese pakkuja järele. Kolm küsimust aitavad minutitega korda luua. Esiteks: kas kõigepealt kindlustatakse ja alles siis muudetakse? Kes kohe „koristab“, blokeerib hilisema selgitamise. Teiseks: kas leitu ja tehtu pannakse kirja? Ilma dokumentatsioonita ei saa sellega midagi peale hakata ei kindlustaja ega andmekaitsespetsialist. Kolmandaks: kas nimetatakse piire? Pakkujasse, kes kuulutab kõik teostatavaks enne, kui on süsteemi näinud, tuleb suhtuda ettevaatlikult.

Kontrollige ka, kas teenusepakkuja mõistab teie töörežiimi. PHP-FPM, Apache koos mod_php-ga, php-cgi, FrankenPHP ja LiteSpeed käituvad paikamisel erinevalt ning pärast uuendust tuleb kõik protsessid uuesti käivitada, muidu jääb vana seis mälus edasi tööle.

## Mida hädaolukorra teenusepakkuja ei suuda

On kasulik piire ette teada. Ükski teenusepakkuja ei saa tagasiulatuvalt luua logisid, mida pole kunagi kirjutatud või mis on juba üle kirjutatud. Puuduvate jälgede korral nimetame lüngad avameelselt. Ka ei saa keegi tagada, et puhastatud süsteemi enam kunagi ei rünnata. Ja õigusnõu ei kuulu meie ülesande hulka: teavitamiskohustuste, vastutuse ja kindlustuse küsimused lähevad andmekaitsespetsialistidele, advokaadile ja kindlustajale, meie annab neile tehnilised faktid.

## Mida peaksite meile saatma

- juhtumi lühikirjeldus ja ajapunkt, mil see silma jäi
- mõjutatud domeenid, serverid ja, kui teada, PHP versioon
- majutaja nimi ja lepingu liik (jagatud veebimajutus, vServer, root-server, hallatav server)
- kontaktisik, kellel on otsustusõigus
- olemasolevad varukoopiad ja nende seis

## Miks PHP SOS

Töötame Saksamaal tehtud (Made in Germany) lahendustega ja oleme koos oma küberspetsialistide partnervõrgustikuga spetsialiseerunud IT-turvalisusele üle 25 aasta. Räägite kindla kontaktisikuga, töötame kaugteel kogu Saksamaal ja Euroopas ning dokumenteerime iga sammu. Ütleme avameelselt, mis on tõendatud ja mis mitte, ning me ei anna lubadusi, mida ükski tõsiseltvõetav teenusepakkuja anda ei saa. Meie järjekord on alati sama: kõigepealt kindlustada, siis muuta, siis aru anda.

## Kas see puudutab teid? Helistage. Me aitame.

Ärge otsige juhtumi ajal edasi sobivat teenusepakkujat. Helistage või kirjutage WhatsAppis, võtame töö üle esimesest sõnumist. [Teatage nüüd hädaolukorrast](https://phpsos.de/et/notfall/).


## Korduma kippuvad küsimused

**Kuidas tunda ära hea IT-hädaolukorra teenusepakkuja?**  
Ta kindlustab jäljed, enne kui midagi muudab, eristab avameelselt tõendatut ja oletatut, dokumenteerib iga sammu ega luba imesid. Umbusklik olge väidete suhtes nagu „kõik garanteeritult puhas“, sest seda ei saa keegi tõsiselt tagada.

**Milliseid ligipääse vajab teenusepakkuja IT-hädaolukorras?**  
Tavaliselt SSH- või haldusliidese ligipääsu serverile, ligipääsu CMS-i halduspoolele ja andmebaasile või teie luba rääkida majutajaga. Andke ainult see, mis on vajalik, ja pange kirja, kes millal millise ligipääsu sai.

**Kas vajan kaugligipääsuks andmetöötluslepingut?**  
Kui teenusepakkuja pääseb ligi süsteemidele, kus on isikuandmeid, on tavaliselt vaja andmetöötluse kokkulepet. Hinnangu annavad andmekaitsespetsialistid või advokaadid. Selgitame selle teiega kohe alguses.

**Mis vahe on intsidendile reageerimisel (Incident Response) ja pahavara eemaldamisel?**  
Pahavara eemaldamine puhastab nakatunud süsteemi. Incident Response on laiem: see hõlmab olukorrapilti, tõkestamist, puhastamist, kommunikatsiooni ja järeltööd, sageli mitme süsteemi üle.

**Kas minu majutaja tuleb kaasata?**  
Sageli jah, näiteks hetktõmmiste (snapshot), logide või blokeeringute tühistamise jaoks. Kooskõlastame end teie majutajaga, kui te seda lubate. Mida saab kontrollida, sõltub õigustest, mille me saame.

## Allikad

- [BSI: Saksamaa föderaalne infoturbeamet](https://www.bsi.bund.de/)
- [BSI IT-baaskaitse (IT-Grundschutz)](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)
- [IKÜM art 33: teavitamine järelevalveasutusele](https://dsgvo-gesetz.de/art-33-dsgvo/)
