© Brian Jackson / 123rf.com

Security und Compliance sind in der Cloud und in Containern ebenso wichtig wie in konventionellen Setups. Das Linux-Magazin stellt aktuelle Entwicklungen und Tools vor und geht auf wichtige Details ein.

Sicherheit ist in der IT heute ein omnipräsentes Thema. Auch in der IT gilt, dass Vertrauen in der Beziehung zwischen Dienstleister und Kunde eine harte Währung ist. Wer dem eigenen Anbieter vertraut, wird sich kaum nach einem neuen umschauen. Sicherheitsprobleme würden da nicht ins Bild passen.

Klar ist deshalb: Macht ein IT-Dienstleister in Sachen Compliance und Sicherheit seine Hausaufgaben nicht, kann das früher oder später die ganze Firma gefährden. Das gilt umso mehr, als mittlerweile auch die Gesetze empfindliche Strafen vorsehen, falls Unternehmen gegen die grundsätzlichen Regeln von Datenschutz und Compliance verstoßen. Strafen nach DSGVO erreichen bei großen Firmen ohne Schwierigkeiten den siebenstelligen Euro-Bereich – Zahlungen, die man sich gern erspart.

Ganz so einfach, wie es im ersten Augenblick klingt, ist die Sache aber nicht. Die Komplexität von IT-Dienstleistungen ist im vergangenen Jahrzehnt kontinuierlich gestiegen. Dazu trägt gerade auch der berüchtigte Layer-Cake bei, aus dem viele Setups heute bestehen: an der Basis eine Cloud mit Software Defined Networking, Orchestrierung und Automatisierung; darüber eine Container-Plattform wie Kubernetes. Hinzu kommt zum Beispiel noch Software Defined Storage, bei dem etwa Verschlüsselung eine Rolle spielt und so weiter und so fort.

Daher gibt es bei einem modernen IT-Setup längst nicht mehr ein einzelnes Team, das sich um alle Komponenten der Installation kümmert. Stattdessen betreibt ein Team oft die virtuellen Maschinen in der Cloud, ein zweites entwickelt und betreibt auf diesen VMs die Container und die darin befindlichen Applikationen. Schon die Kommunikation ist da eine potenzielle Fehlerquelle, von grundlegenden Themen wie einem stimmigen Rollenkonzept ganz zu schweigen.

Welche Faktoren sollten Unternehmen also in Betracht ziehen, um zu einem möglichst schlüssigen Security- und Compliance-Konzept für Dienste in Clouds und Containern zu kommen? Gibt es so etwas wie den Goldstandard, um möglichst viele Probleme von vornherein auszuschließen? Dieser Artikel liefert ein paar grundsätzliche Denkanstöße, gerade für die Planung von Clouds und virtuellen Umgebungen.

Saubere Planung ist alles

Wer sich mit Virtualisierung in Clouds und Container-Anwendungen schon länger beschäftigt, der hält das Thema möglicherweise für mehr als ausreichend diskutiert. Das ist aber nicht der Fall. Viele, gerade auch große Firmen befassen sich aktuell zum ersten Mal überhaupt mit dem Thema Cloud (und noch gar nicht mit dem Thema Container). Sie stehen dann wie der sprichwörtliche Ochse vor dem Berg – und tun, was die meisten in solch einer Situation täten: Sie beginnen auf der grünen Wiese damit, die Technik kennenzulernen und zu erforschen.

Gegen diese Strategie spricht grundsätzlich auch nichts, doch birgt sie stets die Gefahr, halbseidene Lösungen für produktionsreif zu erklären. Halbseiden, weil die Ergebnisse beliebiger Experimente zwar im Einzelfall oft wertvolle Erkenntnisse bringen; es fehlt aber der größere Zusammenhang. Die Frage nach Benutzerzugängen macht das deutlich: OpenStack ist mit den Werkzeugen der verbliebenen OpenStack-Lieferanten – allen voran Canonical und Red Hat – zwar schnell installiert. Kommt man allerdings später darauf, dass man eigentlich das firmeninterne Active Directory gern als Benutzerdatenbank auch für OpenStack verwendet hätte, ist das mit erheblichen Mühen verbunden. Es fällt jedenfalls mehr Aufwand an, als nötig gewesen wäre, hätte man sich von Anfang an um die Integration von Active Directory und OpenStack gekümmert.

Verschiedene Ebenen, verschiedene Maßnahmen

Damit sich solche Fehler vermeiden lassen, empfiehlt es sich, ein Setup für die Virtualisierung von Anfang an in drei Ebenen zu planen. Die unterste Ebene ist die Infrastruktur, also das nackte Blech. Ohne physischen Server lässt sich trotz allen Geredes von “serverless” bis heute kein Kubernetes betreiben.

Die zweite Ebene betrifft die Virtualisierung: Kommt nur Container-Virtualisierung zum Einsatz, geht es hier meist um Kubernetes, etwa in einer Public Cloud. Soll hingegen eine In-House-Lösung realisiert werden, erweitert sich diese Ebene meist noch um eine Software zur Virtualisierung, beispielsweise OpenStack. Die dritte Ebene bildet die eigentliche Anwendung. Auch hier existieren grundlegende Regeln im Hinblick auf die Sicherheit, die bereits von Anfang an Beachtung finden sollten.

Im Folgenden geht dieser Artikel exemplarisch auf jede der drei Ebenen ein und greift die grundlegenden Fragen auf, die Admins in Sachen Security und Compliance im Hinterkopf haben sollten.

Ebene 1: Die Infrastruktur

Viele Unternehmen vollziehen die Migration in die Cloud heute auch deshalb, weil sie sich mit dem Betrieb von Infrastruktur selbst nicht mehr befassen wollen. Allerdings gibt es Situationen, in denen das aus Gründen der Compliance nicht möglich oder auch ganz banal nicht gewollt ist.

Grundsätzlich spricht ja gar nichts dagegen, eine eigene Virtualisierungsplattform zu haben und zu betreiben. Das gilt um so mehr, da Amazon & Co. nicht gerade günstig sind und für Dienstleistungen wie virtuelle CPUs oder virtuelles RAM ein Vielfaches der Herstellungskosten berechnen. Selbst lassen sich diese Dienstleistungen zumindest auf lange Sicht deutlich günstiger herstellen.

Wer heute ein skalierbares Setup neu plant, der sollte sich zunächst vor Augen führen, dass eine skalierbare Umgebung viele Mantras der Vergangenheit unmöglich macht. Die strikte Trennung zwischen Servern, Netzwerkkomponenten und Storage-Systemen etwa fällt weg: In Clouds ist der Speicher ebenso wie das Netz regelmäßig Software-Defined, und auf der Netzwerkebene kommen weitere Faktoren wie EVPN hinzu, die ebenfalls zur Skalierbarkeit beitragen. Die gute Nachricht: So viele Faktoren gibt es auf der Ebene der Infrastruktur gar nicht zu beachten, um ein grundlegendes Sicherheitslevel zu erreichen.

Ein funktionales Rollenkonzept als A&O

Ein sinnvoller Ansatz zum Verwalten von Nutzern und Rollen auf der Ebene der echten Infrastruktur ist von größter Bedeutung, sowohl im Hinblick auf Security als auch im Hinblick auf Compliance. Wer mit Dutzenden Netzwerkgeräten und Hunderten Servern zu tun hat, kann die Verwaltung der Nutzer nicht händisch und auf jedem System einzeln erledigen. Funktional ist hier nur ein Ansatz, der das Arbeiten mit einem zentralen Verzeichnis ermöglicht. Verlässt etwa ein Kollege das Unternehmen, muss es genügen, dessen Account im zentralen Nutzerverzeichnis zu deaktivieren, ohne auch noch jeden Server anzufassen.

Das bedeutet konkret auch: Wer nicht schon ein zentrales Benutzerverzeichnis im Unternehmen hat, beginnt im ersten Schritt damit, ein solches anzulegen. Als sehr nützlich hat sich dabei FreeIPA (Abbildung 1) herausgestellt: Darin steckt im Kern ein LDAP, das sich bei Bedarf aber auch mit bestehenden Benutzerverzeichnissen wie Active Directory kombinieren lässt. FreeIPA hat noch einen anderen nützlichen Nebeneffekt: Das Produkt fungiert auch als SSL Certificate Authority (CA) auf Basis von Certmonger und stellt auf Zuruf lokale SSL-Zertifikate aus. Wer die FreeIPA-CA per Automation auf seinen Hosts als vertraute CA hinterlegt, bekommt die Gelegenheit, sämtliche internen Kommunikationslinks per SSL zu verschlüsseln.

Abbildung 1: Ein funktionales Nutzer- und Rollenkonzept ist die Wurzel sämtlicher Bemühungen um Sicherheit in verteilten Umgebungen. Quelle: FreeIPA

Hosts gehören ins Verzeichnis

Apropos Automation: Besser noch ist es, Hosts automatisch in ein Verzeichnis wie FreeIPA aufzunehmen. Im konkreten Beispiel erledigt diese Aufgabe der FreeIPA-Client, der auf dem System automatisch die FreeIPA-CA hinterlegt und auch Dienste wie PAM so einrichtet, dass das Login mit Nutzern aus dem Verzeichnis klappt.

Im Benutzerteil des zentralen Verzeichnisses legt der Admin dann im Idealfall noch eine Gruppe für Systemadministratoren an, sodass nur diesen ein Login auf den physischen Zielsystemen erlaubt ist. Zudem sollte der Admin darauf achten, Infrastruktur-Hardware wie Netzwerk-Switches ebenfalls in das zentrale Verzeichnis zu integrieren, soweit es denn möglich ist. Setzt man auf ein ONIE-Gerät mit Linux-Schnittstelle, ist das leicht. Hersteller wie Cisco, Juniper & Co. haben aber oft eine ganz eigene Vorstellung davon, wie diese Art der Integration zu erfolgen hat (Abbildung 2).

Abbildung 2: Je nach genutzter Infrastruktur lassen sich auch Netzwerkkomponenten an LDAP & Co. ankoppeln – hier am Beispiel von Cumulus Linux auf Mellanox-Switches.

Auch andere Maßnahmen können helfen

Ein zentrales Benutzerverzeichnis dient viel mehr der Compliance als der konkreten Umsetzung von sicherheitsrelevanten Ansätzen. Die Idee ist ganz simpel: Benutzerzugänge, die es auf dem System nicht mehr gibt, machen auch keinen Ärger und lassen sich nicht missbrauchen. Das Sicherheitskonzept sollte allerdings auch solchen Funktionen Rechnung tragen, die tatsächlich zur Sicherheit beitragen. Das bereits erwähnte Verschlüsseln aller internen Verbindungen ist da nur der erste Schritt.

Ein weiterer Tipp dürfte vielen Admins nicht schmecken, was jedoch an seiner Richtigkeit nichts ändert: Die meisten großen Distributoren wie Red Hat und Canonical richten bei ihren Distributionen die Mandatory Access Control (MAC) nicht aus Spaß an der Freude ein, sondern weil sie einen tatsächlichen Nutzen hat. Dem klassischen Permission-Schema aus dem POSIX-Standard fehlt für die Komplexität moderner Anwendungen schlicht die Flexibilität.

MAC via AppArmor oder SELinux erweitern es deshalb. Beide Lösungen sind allerdings nicht sonderlich angenehm zu bedienen, weshalb viele Admins sie in einer Art Automatismus gleich ganz am Anfang deaktivieren. Empfehlenswert ist das aber nicht: MAC leistet im Hinblick auf Security wertvolle Dienste und lässt sich durchaus sinnvoll einrichten [1].

Cgroups, Namespaces, Lockdown-Modus

Auch sonst bietet Linux mittlerweile viele Möglichkeiten, um die Sicherheit auf Hosts zu erhöhen. Cgroups und Namespaces sind gute Beispiele dafür: Sie schaffen virtuelle Netzwerk-Stacks oder Prozesstabellen auf Systemen, die untereinander nicht kommunizieren können.

Ganz trivial ist es allerdings nicht, Lösungen wie OpenStack mit diesem Features zu verknüpfen. Hier helfen Container: Wer OpenStack betreiben möchte, sollte sich eher am Kolla-Projekt und dessen Containern orientieren, die Cgroups und Namespaces implizit nutzen. Ähnliches gilt für den Lockdown-Modus des Linux-Kernels: Diese noch recht neue Erfindung erlaubt es, Teilbereiche des Kernels sogar vor dem Zugriff durch Root zu schützen.

Ans Herz gelegt sei Admins an dieser Stelle obendrein das kleine Werkzeug InSpec von Chef. Es erfindet eine deklarative Sprache, um Compliance-Regeln in maschinenlesbarer Form zu definieren. Auf Zuruf prüft es auch gleich, ob auf einem bestimmten System diese Regeln eingehalten werden. Trifft es auf Unterschiede zwischen Soll- und Istzustand, schlägt es Alarm und verrät dem Admin, wo er nachfassen muss.

Besonderheiten bei Public Clouds

Die beschriebenen Faktoren spielen freilich überhaupt nur dann eine Rolle, wenn man sich um den Betrieb der Hardware selbst kümmert. Lagert man diese Aufgabe an einen Public-Cloud-Anbieter aus, fällt der größte Teil der beschriebenen Aufgaben schlicht gar nicht an.

Dafür ergeben sich andere Notwendigkeiten, die ebenfalls das Rollen- und Rechtekonzept betreffen. Ein solches ist auch für virtuelle Kunden in Cloud-Umgebungen ebenso nötig wie hilfreich. Wer bereits ein laufendes Active Directory oder LDAP hat, erledigt den Schritt aber im Vorbeigehen: Die Public Clouds der großen Hersteller lassen sich mit Verzeichnisdiensten vor Ort verbinden. So lassen sich bestehende Rechte-Schemata auch auf Ressourcen etwa in AWS anwenden.

Ebene 2: Virtualisierung & Container

Wer sein Blech im Griff und ein funktionales Benutzer- und Rollenkonzept implementiert hat – oder diese Aufgabe einem Public-Cloud-Anbieter überträgt – sieht sich unmittelbar den Herausforderungen der Ebene 2 in virtuellen Setups gegenüber: der Ebene des Virtualisierungsmanagers.

Je nach Setup trifft man hier auf mehr oder weniger Komplexität: Wer Kubernetes in einer Public Cloud nutzt, der kümmert sich nur um dessen Security und Compliance. Betreibt man jedoch die Software zur Virtualisierung selbst, spielt diese ebenfalls eine Rolle. Das Beispiel OpenStack macht das sehr deutlich: Wie fleißig man auch immer die Server wartet und wie gut man die Netzwerk-Hardware unter Kontrolle hat – OpenStack selbst stellt als Software ebenfalls Anforderungen an die Themen Sicherheit und Compliance.

Zum Glück lassen die sich zumindest im OpenStack-Beispiel recht einfach abhandeln. Auf Server-Ebene setzt OpenStack ganz banal darauf, dass der Host vorgibt, was Sache ist. In OpenStack selbst spielt dann eher das Thema Benutzerverwaltung eine Rolle. Hier tut der Admin gut daran, das bestehende System zu übernehmen und OpenStack daran anzuschließen.

Die in OpenStack zuständige Komponente für Authentifizierung heißt Keystone und lässt sich per LDAP-Protokoll mit den gängigen Verzeichnisdiensten ohne große Hürden verbinden. Mehrere Verbindungen parallel sind übrigens möglich: Wer also die Nutzer für interne Dienste aus einem LDAP bekommt, eine externe Kundendatenbank aber in einem anderen LDAP verwaltet (oder in einem anderen Zweig desselben LDAPs), richtet in OpenStack einfach mehrere LDAP-Backends in Keystone ein.

Nutzer und Rollen auch in VMs

Wer klassischen IaaS-Workload in einer Cloud betreiben möchte, ist in Sachen Benutzer und Rechte hier fast am Ende der Fahnenstange angekommen. Aber eben nur fast: Die VMs in der Cloud sollten beim Thema Sicherheit nicht unter den Tisch fallen.

Dabei stellt sich eine besondere Herausforderung: Aus gutem Grund gibt es zwischen dem Underlay-Netz einer Cloud und den Overlay-Netzen der Kunden in einer Cloud eine Trennung. Aus dem Overlay heraus wird es in den meisten Fällen gar nicht möglich sein, auf dieselbe Instanz eines Directory-Servers zuzugreifen, die auch das Underlay nutzt. Es empfiehlt sich dennoch, eine Kopie des Verzeichnisses etwa in einer Slave-Instanz in der Cloud laufen zu lassen: Die virtuellen Instanzen in der Cloud sollten dasselbe Rechtekonzept implementieren wie die Infrastruktur darunter.

Auch sonst gelten für das Thema Sicherheit in diesen Instanzen dieselben Regeln wie auf der Ebene des echten Blechs darunter: MAC sollte eingeschaltet sein; Container helfen dabei, Privilege Separation zu implementieren, und wer kann, sollte Features wie den Lockdown-Modus des Linux-Kernels nutzen.

Das Thema Rollen- und Rechtekonzept holt einen übrigens auch auf der Ebene der genutzten Container-Lösung wieder ein. Fußt diese im Kern auf Kubernetes, wie es heute bei den meisten Produkten der Fall ist, unterstützt auch sie die Anbindung an einen zentralen Verzeichnisdienst. Der Admin tut gut daran, diese Funktionalität zu nutzen und seine Benutzerverwaltung auch auf der Kubernetes-Ebene zu etablieren. Dann ergibt sich ein nahezu vollständiger Trail in Sachen Nutzer- und Rollenkonzept über die komplette (virtuelle) Infrastruktur der Plattform – was sich im Alltag als ausgesprochen praktisch herausstellt.

Die Sicherheit von Passwörtern

Auf der zweiten Ebene des Setups gibt es einen letzten Faktor, der bei Admins gern in Vergessenheit gerät: die Frage nach der sicheren Anmeldung an der Cloud und der sicheren Handhabung von Passwörtern. Es hilft schließlich gar nichts, wenn es zwar ein zentrales Konzept für Nutzer und Rollen gibt, dieses aber durch ein verlorengegangenes Passwort ausgehebelt wird.

Wie auch sonst in der IT gehört es mittlerweile zum guten Ton, Infrastruktur durch Multi-Faktor-Authentifizierung vor Angriffen zu schützen. Die Public Clouds bieten diese Möglichkeit samt und sonders; hier legt ein Admin einfach das zweite Merkmal fest, das er zur Anmeldung nutzen will, und fertig ist die Geschichte. Wer einen AWS- oder Azure-Zugang für eine Firma verwaltet, kann per zentraler Einstellung auch vorgeben, dass alle Benutzer für ihren Zugang einen zweiten Faktor konfigurieren müssen (Abbildung 3).

Abbildung 3: Wer in OpenStack mit Passwörtern hantieren muss, kann diese zentral und gesichert in Barbican ablegen. Quelle: OpenStack

Etwas weniger komfortabel ist die Situation naturgemäß bei On-Premise-Lösungen wie OpenStack. Auch hier ist MFA aber per Time-Based One Time Password (TOTP) zu erreichen. Hinter der sperrigen Bezeichnung verbergen sich letztlich Tokens mit Ablaufdatum, wie sie etwa der Google-Authenticator ausgibt (Abbildung 4).

Abbildung 4: Multi-Faktor-Authentifizierung gehört in verteilten Umgebungen zum guten Ton und lässt sich etwa über FreeIPA auch für On-Premise-Lösungen bauen. Quelle: FreeIPA

Viele Public-Clouds und auch OpenStack als Triebfeder für private Umgebungen bieten übrigens eigene Dienste, die Anwendern das Benutzen von Passwörtern erleichtern. Das bezieht sich explizit nicht auf die Passwörter, die die Nutzer brauchen, um sich an der Cloud anzumelden. Wer jedoch in der Cloud mit Credentials hantiert und diese sicher ablegen möchte, greift dafür idealerweise auf Dienste wie Barbican zurück – vorausgesetzt freilich, der Cloud-Betreiber hat sie zusammen mit der Plattform ausgerollt.

Ebene 3: Tatsächlicher Workload

Bis hierhin hat dieser Artikel sich kaum mit der Frage beschäftigt, wie sich denn tatsächlicher Workload in virtuellen Umgebungen absichern lässt. Das ist zumindest zum Teil unliebsamer Effekt des so oft beklagten Ebenenkuchens, bei dem sehr viel sehr komplexe Infrastruktur nötig ist, um produktive Workloads zu betreiben.

Hinzu kommt, dass für den Workload in Clouds andere Anforderungen gelten als für die Infrastruktur darunter. Ein durchgehendes Nutzer- und Rollenkonzept hilft innerhalb der Container eines virtuellen Setups kaum weiter, wenn die Applikation nicht den Anwendern eines spezifischen Verzeichnisses – etwa des Firmen-LDAPs – vorbehalten ist.

Wer den Workload in Clouds sicher und in Übereinstimmung mit Compliance-Regeln abwickeln möchte, braucht stattdessen ein anderes Regelwerk – und greift an so mancher Stelle doch wieder auf die Fähigkeiten der Infrastruktur zurück.

Sichere Kommunikation ist wichtig

Es wirkt etwas grotesk, dass mancher Zeitgenosse im Jahr 2020 noch immer eine Diskussion über die Frage für nötig hält, ob man die Kommunikation einzelner Dienste untereinander verschlüsseln soll, wenn die Dienste zum selben Setup gehören. Denn SSL-Verschlüsselung kostet nichts mehr, sie ist lokal jederzeit verfügbar. Der Mehraufwand bei der Implementierung hält sich zudem in engen Grenzen.

Das gilt für Mikroarchitektur-Anwendungen umso mehr: Wer etwa auf Istio setzt und sein Mesh-Netz in einer virtuellen Umgebung durch Istio implementieren lässt, bekommt SSL-Verschlüsselung quasi frei Haus. Tatsächliche Gründe, SSL hier nicht zu nutzen, gibt es praktisch nicht (Abbildung 5).

Abbildung 5: Istio kümmert sich, richtig eingesetzt, um die automatische SSL-Verschlüsselung der Kommunikation. Quelle: Istio

Die Nutzung von Mesh-Hilfen wie Istio bietet obendrein den Vorteil einer fertig modellierten Netzwerkumgebung auf Standardbasis. Indem die Entwickler von Applikationen sich die Vorarbeit der Entwickler von Istio, Envoy & Co. zunutze machen, umschiffen sie von vornherein Probleme, die die marktüblichen Lösungen bereits gelöst haben.

Daten verschlüsselt ablegen

Im Hinblick auf Compliance-Vorgaben sind Grundregeln beim Ablegen von Daten wichtig. Die DSGVO etwa spricht etwas schwammig stets davon, beim Ablegen von Daten Schutzmaßnahmen zu ergreifen, die gängigen Best Practices entsprechen, ohne auf Details einzugehen.

Ein probater Weg, die Sicherheit vorgehaltener Daten zu erhöhen, ist die Ablage auf verschlüsselten Volumes. Je nach Kontext kann das im Rahmen der Separation of Interests sogar geboten sein – etwa dann, wenn eine Abteilung einer Firma Daten in einer On-Premises-Cloud anlegt, auf die das Team, das die Cloud betreibt, nicht zugreifen darf.

Ob verschlüsselte Volumes eine Option sind, hängt von der genutzten Storage-Lösung und der Qualität ihrer Integration in OpenStack ab. Entsprechende Überlegungen sollten insofern schon in die Planung einer Cloud einfließen, damit der Katzenjammer anschließend nicht groß ist.

Fazit: Möglich, nicht mühsam

Wer bei seinen Abenteuern in der Cloud ein paar einfache Grundregeln beachtet, der erhöht die Sicherheit quasi im Vorbeigehen erheblich. Ein zentrales Rechtekonzept, das die Admins über möglichst viele Ebenen des Setups hinweg beibehalten, ist ein kritischer Erfolgsfaktor. Es sollte deshalb ein passendes Konzept geben, das auch vorhandene Lösungen einbezieht, noch bevor die ersten Arbeiten an einer Cloud passieren – selbst wenn diese auf der grünen Wiese stattfinden.

Ein fundamentaler Unterschied ergibt sich zwischen der Sicherheit der Infrastruktur und der Sicherheit von Workloads. Während Ansätze wie MCA, der Lockdown-Modus des Linux-Kernels und andere Mechanismen in der Infrastruktur gut funktionieren, gelten für die darauf kaufenden Applikationen andere Regeln. Hier spielt das sichere Ablegen von Daten auf Volumes mit Verschlüsselung eine ebenso große Rolle wie das Absichern des Setups über die Mechanismen der Plattformen. OpenStack, Kubernetes & Co. gehen hier aber mit gutem Beispiel voran und ermöglichen in der Standardkonfiguration Zugriffe von außen gar nicht.

Klar ist jedenfalls: Ob ein Setup sich in Sachen Security und Compliance richtig entwickelt, entscheidet sich, noch bevor der erste Server installiert ist. Planung ist alles, und verpasste Planung lässt sich kaum nachholen. (jcb)