# Sicherheitsbewusstsein für Admins und Redakteure: Security Awareness im Web-Team

> Security Awareness für Admins und Redakteure: welche Risiken je Rolle zählen, wie kurze Schulungen wirken und wie Sie ein Web-Team in 90 Tagen fit machen.

Quelle: https://phpsos.de/blog/sicherheitsbewusstsein-redaktion/  
Stand: 25.10.2026  
Anbieter: PHP SOS, PHP-Notfallhilfe und Server-Sicherheit. Soforthilfe per WhatsApp: https://wa.me/491736494914?text=Hallo%20PHP%20SOS%2C%20wir%20brauchen%20Hilfe%20mit%20unserem%20PHP-Server.%20Firma%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**Kurz gesagt:** Security Awareness für Mitarbeiter im Web-Team heißt: Jede Person, die eine Website pflegt, kennt die drei bis vier Risiken ihrer Rolle, erkennt Auffälligkeiten und meldet sie schnell und ohne Angst vor Vorwürfen. Redakteure brauchen andere Inhalte als Admins. Kurze, wiederkehrende Einheiten mit Beispielen aus dem eigenen CMS wirken besser als eine jährliche Pflichtschulung.

## Warum gerade jetzt das Web-Team im Mittelpunkt steht

Die Lage um PHP2Shell hat gezeigt, wie viel in wenigen Tagen auf Betreiber von Websites einprasselt: Warnungen des BSI, Meldungen von Hostern, Ratschläge in Foren und sozialen Netzwerken, darunter auch falsche. In solchen Wochen entscheiden nicht nur Admins, sondern auch Redakteure, Marketing und Assistenz, welche Mail sie öffnen und welchen Link sie anklicken.

Große Nachrichtenlagen sind erfahrungsgemäß ein Anlass für Betrüger. Rechnen Sie mit Mails, die sich als Hoster, CMS-Hersteller oder „IT-Abteilung“ ausgeben und zu einer dringenden Anmeldung oder einem angeblichen Sicherheitsupdate auffordern. Wer die echte Lage kennt, fällt darauf seltener herein. Die technische Lücke selbst schließt kein Redakteur, aber ein gestohlener Admin-Zugang öffnet die Tür auch ohne Lücke.

## Security Awareness für Mitarbeiter: Wer braucht was?

Eine Schulung für alle mit denselben Folien verfehlt meist ihr Ziel. Sinnvoller ist ein Zuschnitt nach Rollen. Die folgende Übersicht hilft bei der Planung:

| Rolle | Typische Risiken | Was die Person können sollte |
|---|---|---|
| Redakteur, Marketing | Phishing-Mails, unsichere Datei-Uploads, geteilte Zugänge | Absender prüfen, nur erwartete Dateitypen hochladen, eigene Zugangsdaten nie weitergeben |
| CMS-Administrator | Plugins aus unbekannter Quelle, zu viele Admin-Konten, alte Konten ehemaliger Mitarbeiter | Rechte sparsam vergeben, Konten regelmäßig prüfen, Erweiterungen nur nach Freigabe |
| Server-Admin | Ungeprüfte Tipps aus dem Netz, Änderungen ohne Protokoll, vergessene Testdateien | Quellen bewerten, Änderungen dokumentieren, Notfallweg kennen |
| Geschäftsführung | Druck auf schnelle Entscheidungen, unklare Zuständigkeiten | Entscheidungswege festlegen, Meldungen ernst nehmen, Budget für Vorsorge freigeben |
| Externe Agentur | Gemeinsame Zugänge, fehlende Absprachen | Eigene, persönliche Konten nutzen, Änderungen ankündigen |

Die Tabelle zeigt auch, wo Technik helfen muss. Persönliche Konten statt Sammelzugängen und eine Zwei-Faktor-Anmeldung für alle mit Schreibrechten nehmen viel Druck von der Schulung. Wie das geht, steht unter [Zwei-Faktor-Anmeldung für Admin-Zugänge](https://phpsos.de/ratgeber/zwei-faktor-admin/).

## Was Redakteure wissen müssen, ohne Techniker zu werden

Redakteure müssen nicht wissen, was ein PHP-Worker ist. Sie sollten aber drei Dinge sicher beherrschen. Erstens: Eine Aufforderung, sich „wegen eines Sicherheitsvorfalls“ neu anzumelden, wird nie über den Link in der Mail erledigt, sondern über den gewohnten Weg ins CMS oder per Rückfrage beim Admin.

Zweitens: Auffälligkeiten melden. Dazu gehören unbekannte Benutzerkonten in der Benutzerliste, Seiten oder Beiträge, die niemand angelegt hat, plötzliche Weiterleitungen und Warnungen im Browser. Ein Redakteur sieht die Website oft häufiger als der Admin und bemerkt Veränderungen früher.

Drittens: Uploads bewusst behandeln. Bilder und PDFs sind Alltag, aber eine Datei mit ungewohnter Endung, ein Archiv „zur Weiterleitung“ oder ein Dokument mit Makros gehört nicht ins CMS. Wenn eine Datei nicht hochgeladen werden kann, ist das meist Absicht und kein Fehler, den man umgehen sollte.

## Was Admins zusätzlich brauchen

Für Admins geht es weniger um Phishing als um Urteilskraft unter Zeitdruck. In der PHP2Shell-Woche kursierten Ratschläge, die Fachautoren ausdrücklich ablehnen, etwa alle Anfragen mit `PHPSESSID` zu blockieren. Eine Übersicht solcher Irrwege bietet der Beitrag [Gefährliche Falschtipps zu PHP2Shell](https://phpsos.de/blog/gefaehrliche-falschtipps/). Gute Admins prüfen zuerst die Primärquelle, also php.net, BSI oder den Hersteller, bevor sie eine Konfiguration ändern.

Dazu gehört Disziplin bei Änderungen: Was wurde wann warum geändert, und wie lässt es sich zurücknehmen? Ein kurzer Eintrag im Ticket oder Wiki reicht. Im Ernstfall ist diese Liste Gold wert, weil sie zeigt, welche Änderung von Ihnen stammt und welche nicht.

Schließlich sollten Admins wissen, woran sie einen möglichen Einbruch erkennen und was dann nicht zu tun ist: nicht hektisch löschen, nicht sofort neu installieren, sondern sichern und melden. Die typischen Anzeichen fasst [Bin ich schon kompromittiert?](https://phpsos.de/php2shell/bin-ich-gehackt-anzeichen/) zusammen.

## In 90 Tagen zu einem wachen Web-Team

Ein Programm muss nicht groß sein, um zu wirken. Diese Schritte haben sich bewährt:

1. **Bestand klären (Woche 1 bis 2):** Wer hat welche Zugänge zu CMS, Hosting, Domain und Server? Sammelkonten auflösen, alte Konten sperren.
2. **Meldeweg festlegen (Woche 2):** Eine Adresse oder ein Kanal für „mir kommt etwas komisch vor“. Jede Meldung wird beantwortet, auch wenn sie harmlos war.
3. **Erste Kurzeinheit je Rolle (Woche 3 bis 4):** 20 Minuten, Beispiele aus dem eigenen CMS, Bildschirmfotos echter Menüs.
4. **Zwei-Faktor-Anmeldung einführen (bis Woche 6):** Für alle mit Schreibrechten, mit Notfallcodes an sicherem Ort.
5. **Übungsmail und Auswertung (Woche 8):** Eine angekündigte Testkampagne ohne Bloßstellung einzelner Personen. Ausgewertet wird, ob gemeldet wurde, nicht wer geklickt hat.
6. **Zweite Einheit zum Anlass (Woche 10 bis 12):** Zum Beispiel eine aktuelle Sicherheitslage, durchgespielt am eigenen System.

Messen Sie den Erfolg an Meldungen, nicht an Klickquoten. Ein Team, das viel meldet, ist wach. Ein Team, das nie meldet, ist entweder perfekt oder verunsichert, und Ersteres ist selten.

## Wie hilft PHP SOS konkret?

- Wir erfassen gemeinsam mit Ihnen, wer welche Zugänge hat, und zeigen Sammelkonten, überzählige Admins und vergessene Zugänge.
- Wir halten Kurzeinheiten je Rolle remote, mit Beispielen aus Ihrem CMS und Ihrer Serverumgebung.
- Wir richten den Meldeweg mit ein und bewerten eingehende Verdachtsmeldungen, wenn Sie das wünschen.
- Im Rahmen eines [Security-Wartungsvertrags](https://phpsos.de/leistungen/security-wartungsvertrag/) wiederholen wir die Einheiten zu aktuellen Anlässen und prüfen die Konten regelmäßig.

## Fazit

Sicherheitsbewusstsein im Web-Team entsteht nicht durch Angst, sondern durch Klarheit: Jeder kennt seine Rolle, seine typischen Risiken und den Weg, Auffälligkeiten zu melden. Kombiniert mit persönlichen Konten und Zwei-Faktor-Anmeldung ist das ein Schutz, der auch in der nächsten Krisenwoche trägt.


## Häufige Fragen

**Brauchen Redakteure überhaupt eine Sicherheitsschulung?**  
Ja. Redakteure haben Zugang zum CMS, laden Dateien hoch und erhalten Mails, die wie Systemnachrichten aussehen. Sie müssen keine Technik verstehen, aber erkennen, wann etwas ungewöhnlich ist, und wissen, wem sie es melden.

**Wie oft sollte man das Web-Team schulen?**  
Besser kurz und regelmäßig als einmal im Jahr lang. Bewährt haben sich Einheiten von 15 bis 20 Minuten im Abstand weniger Wochen, ergänzt um einen Anlass wie eine aktuelle Sicherheitslage.

**Was tun, wenn ein Mitarbeiter auf einen Phishing-Link geklickt hat?**  
Sofort melden lassen, ohne Vorwurf. Dann das betroffene Passwort ändern, aktive Sitzungen beenden und prüfen, ob mit dem Konto etwas verändert wurde. Je früher die Meldung kommt, desto kleiner ist meist der Schaden.

**Ersetzt eine Schulung technische Schutzmaßnahmen?**  
Nein. Schulung und Technik ergänzen sich. Zwei-Faktor-Anmeldung, getrennte Rollen und aktuelle Software fangen Fehler ab, die auch gut geschulten Menschen passieren.

## Quellen

- [BSI: Informationen für Unternehmen](https://www.bsi.bund.de/)
- [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)
- [php.net: Sicherheitsmeldungen](https://www.php.net/)