Έλεγχος OAuth εφαρμογής και permissions σε εταιρικό περιβάλλον Microsoft 365
Αρχική Blog Microsoft 365 & Cloud Ασφάλεια OAuth Consent Phishing στο Microsoft 365: Πώς Κακόβουλες Εφαρμογές Αποκτούν Πρόσβαση στα Εταιρικά Δεδομένα

OAuth Consent Phishing στο Microsoft 365: Πώς Κακόβουλες Εφαρμογές Αποκτούν Πρόσβαση στα Εταιρικά Δεδομένα

Κατηγορία: Microsoft 365 & Cloud Ασφάλεια Δημοσίευση: 10/09/2026

Χρόνος Ανάγνωσης: περίπου 7 λεπτά | Προβολές: 0

Το OAuth consent phishing μπορεί να δώσει σε κακόβουλη εφαρμογή πρόσβαση σε εταιρικά δεδομένα χωρίς να απαιτείται απαραίτητα κλοπή του password του χρήστη.

Ένα phishing attack στο Microsoft 365 δεν χρειάζεται πάντα να κλέψει το password ενός εργαζομένου. Σε ένα OAuth consent phishing σενάριο, ο επιτιθέμενος προσπαθεί να πείσει τον χρήστη να εγκρίνει την πρόσβαση μιας κακόβουλης ή παραπλανητικής εφαρμογής σε εταιρικά δεδομένα.

Αν ο χρήστης δώσει consent, η εφαρμογή μπορεί να αποκτήσει τα permissions που εγκρίθηκαν και να χρησιμοποιεί την εξουσιοδότηση αυτή σύμφωνα με το OAuth model. Για αυτό η προστασία δεν περιορίζεται στο MFA: χρειάζεται έλεγχος των εφαρμογών, των publishers και των permissions που επιτρέπεται να εγκρίνουν οι χρήστες.

Τι είναι το OAuth consent phishing;

Το OAuth είναι ένας μηχανισμός εξουσιοδότησης που επιτρέπει σε μια εφαρμογή να ζητήσει πρόσβαση σε δεδομένα ή λειτουργίες άλλης υπηρεσίας χωρίς να χρειάζεται να γνωρίζει το password του χρήστη.

Στο Microsoft identity platform, μια εφαρμογή μπορεί να ζητήσει συγκεκριμένα permissions. Ο χρήστης ή ένας administrator βλέπει ένα consent prompt και αποφασίζει αν θα εγκρίνει την πρόσβαση.

Το πρόβλημα δημιουργείται όταν ένας επιτιθέμενος κατασκευάσει ή χρησιμοποιήσει μια παραπλανητική εφαρμογή και πείσει τον χρήστη να εγκρίνει permissions που δεν θα έπρεπε να δοθούν. Η σελίδα εξουσιοδότησης μπορεί να αποτελεί μέρος του πραγματικού Microsoft authentication flow, επομένως η απουσία μιας ψεύτικης σελίδας login δεν σημαίνει ότι η διαδικασία είναι ασφαλής.

Τι πρόσβαση μπορεί να αποκτήσει μια εφαρμογή;

Η πραγματική πρόσβαση εξαρτάται από τα permissions που ζητά η εφαρμογή και από το consent που τελικά εγκρίνεται.

Στο Microsoft identity platform υπάρχουν δύο βασικές κατηγορίες permissions:

  • Delegated permissions: η εφαρμογή ενεργεί εκ μέρους ενός συνδεδεμένου χρήστη και η πρόσβασή της περιορίζεται από τα permissions που έχουν δοθεί και από την πρόσβαση του ίδιου του χρήστη.
  • Application permissions: η εφαρμογή μπορεί να λειτουργεί χωρίς ενεργό συνδεδεμένο χρήστη. Αυτού του τύπου τα permissions απαιτούν administrator consent.

Ανάλογα με το API και τα permissions, μια εφαρμογή μπορεί να ζητά πρόσβαση σε email, αρχεία, προφίλ χρηστών ή άλλους Microsoft 365 πόρους. Για αυτό το consent prompt πρέπει να αντιμετωπίζεται ως πραγματική απόφαση πρόσβασης και όχι ως ένα ακόμη μήνυμα που ο χρήστης απλώς αποδέχεται για να συνεχίσει.

Γιατί το MFA δεν αρκεί;

Το MFA προστατεύει τη διαδικασία authentication, αλλά το OAuth consent αφορά authorization: τι επιτρέπεται να κάνει μια εφαρμογή αφού ο χρήστης έχει συνδεθεί.

Ένας εργαζόμενος μπορεί να ολοκληρώσει κανονικά MFA στη Microsoft και στη συνέχεια να εγκρίνει μια επικίνδυνη εφαρμογή. Σε αυτή την περίπτωση το πρόβλημα δεν είναι ότι παρακάμφθηκε απαραίτητα το MFA, αλλά ότι δόθηκε ανεπιθύμητη εξουσιοδότηση.

Παρόμοια, διαφορετικό attack path είναι το Device Code Phishing στο Microsoft 365, όπου επίσης μπορεί να καταχραστεί ένα νόμιμο authentication flow.

Πώς περιορίζεται το επικίνδυνο user consent;

Το Microsoft Entra επιτρέπει στους administrators να καθορίζουν πότε οι χρήστες μπορούν να παρέχουν consent σε εφαρμογές. Η Microsoft συνιστά να περιορίζεται το user consent σε εφαρμογές από verified publishers και σε επιλεγμένα permissions, αντί να επιτρέπεται ανεξέλεγκτη έγκριση εφαρμογών.

Σε περιβάλλοντα όπου το user consent περιορίζεται ή απενεργοποιείται, μπορεί να χρησιμοποιηθεί admin consent workflow ώστε οι χρήστες να υποβάλλουν αίτημα για μια εφαρμογή και ένας εξουσιοδοτημένος administrator να αξιολογεί το αίτημα πριν δοθεί πρόσβαση.

Η απόφαση δεν πρέπει να βασίζεται μόνο στο όνομα της εφαρμογής. Ελέγξτε τουλάχιστον:

  • ποιος είναι ο publisher και αν είναι αυτός που περιμένετε,
  • ποια permissions ζητά η εφαρμογή,
  • αν τα permissions είναι απαραίτητα για τη λειτουργία της,
  • ποια δεδομένα μπορεί να προσπελάσει,
  • αν η εφαρμογή είναι πραγματικά απαραίτητη για την επιχείρηση.

Το ευρύτερο θέμα των third-party integrations και OAuth apps αναλύεται επίσης στον οδηγό για ασφάλεια SaaS εφαρμογών.

Πώς ελέγχετε τι έχει ήδη εγκριθεί;

Οι administrators πρέπει να επανεξετάζουν περιοδικά τις Enterprise Applications και τα permissions που έχουν δοθεί. Ένα application consent που ήταν αποδεκτό όταν εγκαταστάθηκε μια υπηρεσία μπορεί να μην είναι πλέον απαραίτητο μήνες αργότερα.

Ο έλεγχος πρέπει να αναζητά εφαρμογές που δεν αναγνωρίζονται, permissions που είναι ευρύτερα από την πραγματική επιχειρηματική ανάγκη και integrations που δεν χρησιμοποιούνται πλέον.

Η Microsoft παρέχει διαδικασίες για review και revoke των permissions που έχουν δοθεί σε enterprise applications. Πρόσθετες δυνατότητες visibility, policies και app governance υπάρχουν μέσω Microsoft Defender for Cloud Apps, αλλά εξαρτώνται από το διαθέσιμο licensing και τη διαμόρφωση του περιβάλλοντος.

Τι να κάνετε αν εντοπίσετε ύποπτο consent;

Μην περιοριστείτε σε αλλαγή password. Ένα OAuth permission μπορεί να παραμένει ανεξάρτητο από το password που χρησιμοποιήθηκε κατά το αρχικό sign-in.

Σε πιθανό illicit consent grant χρειάζεται, ανάλογα με το περιστατικό:

  1. να εντοπιστεί η εφαρμογή και τα permissions που έχουν δοθεί,
  2. να απενεργοποιηθεί ή να αποκλειστεί η κακόβουλη εφαρμογή,
  3. να ανακληθούν τα αντίστοιχα consent grants ή permissions,
  4. να ελεγχθούν οι χρήστες που έδωσαν consent,
  5. να εξεταστούν σχετικά sign-in και audit events,
  6. να διερευνηθεί αν η εφαρμογή απέκτησε πρόσβαση σε εταιρικά δεδομένα.

Η Microsoft επισημαίνει ότι σε περιστατικό με κακόβουλη εφαρμογή η απενεργοποίηση μπορεί να είναι προτιμότερη από την απλή διαγραφή, ώστε να εμποδιστεί η επανεμφάνισή της μέσω νέου consent.

Πρακτική πολιτική για μια ΜΜΕ

Για μια μικρή ή μεσαία επιχείρηση, ο στόχος δεν είναι να αποκλειστεί κάθε third-party εφαρμογή. Είναι να σταματήσει η ανεξέλεγκτη εξουσιοδότηση.

  • Καθορίστε ποιοι χρήστες επιτρέπεται να εγκρίνουν εφαρμογές.
  • Περιορίστε το user consent σύμφωνα με τις πραγματικές ανάγκες του οργανισμού.
  • Χρησιμοποιήστε διαδικασία admin approval για εφαρμογές που χρειάζονται αυξημένα permissions.
  • Ελέγχετε publisher, permissions και πραγματική επιχειρηματική ανάγκη πριν από κάθε έγκριση.
  • Επανεξετάζετε τακτικά υπάρχουσες εφαρμογές και αφαιρείτε πρόσβαση που δεν χρειάζεται πλέον.
  • Εκπαιδεύστε τους εργαζομένους ώστε να αντιμετωπίζουν ένα consent prompt με την ίδια προσοχή που θα αντιμετώπιζαν ένα αίτημα για credentials.

Οι έλεγχοι αυτοί πρέπει να εντάσσονται στη συνολική στρατηγική ασφάλειας Microsoft 365 και όχι να εφαρμόζονται απομονωμένα.

Συμπέρασμα

Το OAuth consent phishing εκμεταλλεύεται μια νόμιμη λειτουργία εξουσιοδότησης: ο χρήστης πείθεται να δώσει πρόσβαση σε μια εφαρμογή που δεν πρέπει να εμπιστευτεί.

Η αποτελεσματική προστασία συνδυάζει περιορισμένο user consent, προσεκτικό admin approval, τακτικό έλεγχο των Enterprise Applications και γρήγορη ανάκληση ύποπτων permissions. Η DataShield μπορεί να αξιολογήσει τις ρυθμίσεις Microsoft Entra και Microsoft 365 μιας επιχείρησης και να εντοπίσει εφαρμογές, permissions και consent policies που χρειάζονται βελτίωση.

Επίσημες πηγές

Πιστοποιήσεις & Επαγγελματική Κατάρτιση

Η DataShield διαθέτει αναγνωρισμένες πιστοποιήσεις από κορυφαίους οργανισμούς τεχνολογίας.

Google Cybersecurity Professional Certificate — Verified by Google on Credly

Verified by Google & Coursera — October 2025