Lyhyesti: Kaksivaiheinen tunnistautuminen ylläpitotunnuksille huolehtii siitä, ettei varastettu tai arvattu salasana yksin riitä. Sen on oltava voimassa kaikkialla, missä joku voi muuttaa verkkosivustoanne tai palvelintanne: CMS, hosting, paneeli, SSH, verkkotunnus, DNS ja ylläpitäjien postilaatikot. Yhtä tärkeitä kuin käyttöönotto ovat varakoodit ja selvä sääntö siitä, kenellä on mihinkin oma pääsy.
Miksi salasanat eivät yksin riitä ylläpitäjille
Salasanat katoavat monta tietä: tietojenkalastelusähköpostien, työasemalla olevan haittaohjelman, muiden palveluiden tietovuotojen tai pelkän uudelleenkäytön kautta. Automaattiset hyökkäykset kokeilevat varastettuja tunnuksia keskeytyksettä tunnettuja kirjautumissivuja vastaan.
Toisella tekijällä hyökkääjä tarvitsee lisäksi jotain, mikä on vain oikeutetulla käyttäjällä, esimerkiksi älypuhelimen todentajasovelluksella tai turva-avaimen. Se nostaa kynnystä selvästi, etenkin tileillä, joilla on laajat oikeudet.
Johdolle yksi rajaus on tärkeä: kaksivaiheinen tunnistautuminen suojaa pääsyjä, ei niiden takana olevaa ohjelmistoa. Sellaista aukkoa kuin PHP2Shell, joka sallii koodin suorittamisen ilman kirjautumista, se ei sulje. Molemmat kuuluvat yhteen: ajantasainen ohjelmisto ja hyvin suojatut pääsyt.
Mitkä kaksivaiheiset menetelmät sopivat
Menetelmät eroavat turvallisuudessa ja käyttömukavuudessa. Ylläpitäjien tileille kannattaa käyttää vähintään todentajasovelluksia, erityisen kriittisiin pääsyihin turva-avaimia tai pääsyavaimia.
| Menetelmä | Suoja tietojenkalastelua vastaan | Soveltuvuus ylläpitäjille |
|---|---|---|
| Tekstiviestikoodi | vähäinen | vain siirtymänä |
| Todentajasovellus (TOTP) | keskitaso | hyvä vakiotaso |
| Push-vahvistus | keskitaso, altis väsytyshyökkäyksille | sopii numeroiden vertailun kanssa |
| Turva-avain tai pääsyavain (FIDO2/WebAuthn) | korkea | suositeltu kriittisiin pääsyihin |
| SSH-avain salalauseella | korkea | vakio palvelinpääsyille |
Sovelluksen kertakoodit voi siepata petollisen aidolla kalastelusivulla ja käyttää heti edelleen. FIDO2-menetelmät tarkistavat sen sijaan sivun osoitteen eivätkä toimi väärennetyllä sivulla. Siksi ne ovat paras valinta ylläpitäjille, joilla on pääsy moniin järjestelmiin.
Kaksivaiheinen tunnistautuminen ylläpitotunnuksille: täydellinen luettelo
Hyökkääjät valitsevat heikoimman pääsyn. Käykää siksi läpi kaikki kohdat, joissa joku voi muuttaa verkkosivustoanne, palvelintanne tai verkkotunnustanne:
- CMS ja verkkokaupan hallinta: WordPress, Shopware, TYPO3 ja muut tarjoavat kaksivaiheisen tunnistautumisen ytimessä tai ylläpidettyjen laajennusten kautta. Mikä vaihtoehto on suositeltu, kerrotaan valmistajan dokumentaatiossa.
- Hostingin asiakastili: Joka pääsee tänne, voi usein nollata salasanoja, ladata varmuuskopioita tai asentaa palvelimen uudelleen.
- Palvelinpaneeli kuten Plesk tai cPanel, jos sellainen on.
- SSH ja SFTP: Avain salasanan sijaan, katso seuraava kohta.
- Verkkotunnuksen rekisteröijä ja DNS: Muutettu DNS-asetus ohjaa kävijänne ja postinne muualle ilman, että palvelin on kosketettu.
- Ylläpitäjien sähköpostilaatikot: Niiden kautta kulkevat lähes kaikkien muiden palveluiden salasanan nollaukset.
- Koodirepositorio ja deployment: Joka saa kirjoittaa siellä, voi levittää haittakoodia.
- CDN, WAF, Google Search Console ja maksupalveluntarjoajat.
Kirjatkaa jokaisesta kohdasta, kenellä on pääsy, onko toinen tekijä aktiivinen ja missä palautuskoodit säilytetään. Tämä luettelo on samalla tärkeä osa hätäsuunnitelmaanne, sillä poikkeaman jälkeen juuri nämä pääsyt on tarkistettava ja uusittava lyhyessä ajassa.
SSH: avain salasanan sijaan
Palvelinpääsyille kirjautuminen SSH-avaimella on tavanomainen vahva suoja. Yksityinen avain on ylläpitäjän laitteella ja suojattu salalauseella; erityisen suojaa vaativilla palvelimilla se voi olla laitteistoavaimella. Kun avainkirjautuminen on otettu käyttöön ja testattu kaikille ylläpitäjille, poistakaa salasanakirjautuminen käytöstä:
# /etc/ssh/sshd_config (ote)
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey
# Tarkista asetukset, ennen kuin palvelu ladataan uudelleen
sshd -t && systemctl reload ssh # RHEL-järjestelmissä: sshd
Jättäkää muutoksen aikana olemassa oleva istunto auki ja testatkaa kirjautuminen toisessa ikkunassa. Näin ette sulje itseänne ulos virheen sattuessa. Jokainen ylläpitäjä saa oman avaimen; koko tiimin yhteisiä avaimia ei voi yksittäisten henkilöiden lähtiessä peruuttaa siististi. Lisäperusteita kuvataan sivulla Root-palvelimen ja vServerin suojaaminen itse.
Varapääsy ja palautuskoodit
Hyvä käyttöönotto huomioi myös katkot. Älypuhelimet katoavat, työntekijät lähtevät yrityksestä, turva-avaimet menevät rikki. Ilman suunnitelmaa väärällä hetkellä kukaan ei ole valmiina pääsyn kanssa.
Rekisteröikää jokaiselle kriittiselle tilille kaksi tekijää, esimerkiksi turva-avain toimistossa ja todentajasovellus, ja säilyttäkää palautuskoodit erillään salasanasta.
Muita käytännössä toimivia sääntöjä:
- Henkilökohtaiset tilit yhteiskäyttöisten ylläpitokirjautumisten sijaan, jotta muutokset ovat jäljitettävissä.
- Dokumentoitu varapääsy erikseen säilytetyin tunnuksin, jonka käyttö huomataan ja kirjataan.
- Työntekijöiden tai palveluntarjoajien lähtiessä kaikki pääsyt ja avaimet peruutetaan samana päivänä.
- Tietoturvapoikkeaman jälkeen tarkistetaan salasanojen lisäksi myös rekisteröidyt tekijät ja aktiiviset istunnot.
Tiimissä käyttöönotossa on osoittautunut toimivaksi selkeä kulku. Aloittakaa tileistä, jotka voivat aiheuttaa suurimman vahingon: hosting, verkkotunnus, DNS ja ylläpitäjien sähköpostilaatikot. Sen jälkeen tulevat palvelin, CMS ja palvelut. Määrittäkää takaraja, jonka jälkeen kirjautuminen ilman toista tekijää ei ole enää mahdollista, ja varmistakaa ennen sitä, että kaikki osalliset on otettu käyttöön.
Selittäkää tiimille lyhyesti, miksi muutos on tarpeen ja miten se toimii arjessa. Yhden sivun ohje ruutukaappauksin vähentää kysymyksiä selvästi. Ulkopuolisille palveluntarjoajille ja toimistoille pitäisi antaa omat, henkilökohtaiset pääsyt toisella tekijällä yhteisen kirjautumisen sijaan, jotta käyttö pysyy yksilöitävänä ja pääsyn voi projektin päätyttyä peruuttaa siististi.
Miten suojaatte kirjautumissivut lisäksi automaattisia yrityksiä vastaan, kerrotaan oppaassa Ylläpidon kirjautumisten suojaaminen Brute Forcelta.
Miten PHP SOS auttaa konkreettisesti?
- Laadimme kanssanne täydellisen luettelon kaikista ylläpitopääsyistä ja näytämme, missä toinen tekijä puuttuu.
- Siirrämme palvelinpääsyt SSH-avaimiin ja poistamme salasanakirjautumiset hallitusti käytöstä osana palvelimen koventamista.
- Dokumentoimme varapääsyt ja palautusreitit niin, että ne toimivat hätätilanteessa.
- Tietoturvahuoltosopimuksessa tarkistamme pääsyt säännöllisesti ja poistamme orvoiksi jääneet tilit.
Usein kysytyt kysymykset
Mikä kaksivaiheinen menetelmä on turvallisin?
FIDO2-standardin mukaisia laitteistopohjaisia turva-avaimia ja pääsyavaimia (passkey) pidetään erityisen kestävinä tietojenkalastelua vastaan, koska ne on sidottu oikeaan osoitteeseen. Kertakoodeja käyttävät todentajasovellukset ovat hyvä vakiotaso. Tekstiviesti on parempi kuin ei mitään, mutta heikoin vaihtoehto.
Mitä tapahtuu, jos todentajasovelluksen sisältävä älypuhelin katoaa?
Siihen on palautuskoodit, jotka näytetään käyttöönoton yhteydessä. Ne kuuluvat säilyttää turvallisesti, esimerkiksi kassakaapissa tai suojatussa salasanahallinnassa. Lisäksi vähintään yhden toisen ylläpitäjän pitäisi pystyä nollaamaan pääsy.
Suojaako kaksivaiheinen tunnistautuminen myös PHP2Shellilta?
Ei. PHP2Shell sallii koodin suorittamisen ilman kirjautumista, eikä kirjautumista silloin käytetä lainkaan. PHP2Shelliä vastaan auttaa vain päivitys korjattuun PHP-versioon ja kaikkien worker-prosessien uudelleenkäynnistys. Kaksivaiheinen tunnistautuminen suojaa varastetuilta tai arvatuilta salasanoilta.
Riittääkö kaksivaiheinen tunnistautuminen CMS:ssä?
Ei, hyökkääjä valitsee heikoimman pääsyn. Hosting-tili, palvelinpaneeli, SSH, verkkotunnusten hallinta, DNS ja ylläpitäjien sähköpostilaatikot on suojattava yhtä lailla, muuten CMS:n suojan voi kiertää.