Rechercher dans le manuel MySQL
17.3.2.3 Binary Log Master Key Rotation
When binary log encryption is enabled, you can rotate the binary
log master key at any time while the server is running by
issuing ALTER INSTANCE ROTATE BINLOG MASTER
KEY
. When the binary log master key is rotated
manually using this statement, the passwords for the new and
subsequent files are encrypted using the new binary log master
key, and also the file passwords for existing encrypted binary
log files and relay log files are re-encrypted using the new
binary log master key, so the encryption is renewed completely.
You can rotate the binary log master key on a regular basis to
comply with your organization's security policy, and also if you
suspect that the current or any of the previous binary log
master keys might have been compromised.
When you rotate the binary log master key manually, MySQL Server takes the following actions in sequence:
A new binary log encryption key is generated with the next available sequence number, stored on the keyring, and used as the new binary log master key.
The binary log and relay log files are rotated on all channels.
The new binary log master key is used to encrypt the file passwords for the new binary log and relay log files, and subsequent files until the key is changed again.
The file passwords for existing encrypted binary log files and relay log files on the server are re-encrypted in turn using the new binary log master key, starting with the most recent files. Any unencrypted files are skipped.
Binary log encryption keys that are no longer in use for any files after the re-encryption process are removed from the keyring.
The BINLOG_ENCRYPTION_ADMIN
privilege is required to issue ALTER
INSTANCE ROTATE BINLOG MASTER KEY
, and the statement
cannot be used if the
binlog_encryption
system
variable is set to OFF
.
As the final step of the binary log master key rotation process,
all binary log encryption keys that no longer apply to any
retained binary log files or relay log files are cleaned up from
the keyring. If a retained binary log file or relay log file
cannot be initialized for re-encryption, the relevant binary log
encryption keys are not deleted in case the files can be
recovered in the future. For example, this might be the case if
a file listed in a binary log index file is currently
unreadable, or if a channel fails to initialize. If the server
UUID changes, for example because a backup created using MySQL
Enterprise Backup is used to set up a new replication slave,
issuing ALTER INSTANCE ROTATE BINLOG MASTER
KEY
on the new server does not delete any earlier
binary log encryption keys that include the original server
UUID.
If any of the first four steps of the binary log master key
rotation process cannot be completed correctly, an error message
is issued explaining the situation and the consequences for the
encryption status of the binary log files and relay log files.
Files that were previously encrypted are always left in an
encrypted state, but their file passwords might still be
encrypted using an old binary log master key. If you see these
errors, first retry the process by issuing
ALTER INSTANCE ROTATE BINLOG MASTER
KEY
again. Then investigate the status of individual
files to see what is blocking the process, especially if you
suspect that the current or any of the previous binary log
master keys might have been compromised.
If the final step of the binary log master key rotation process
cannot be completed correctly, a warning message is issued
explaining the situation. The warning message identifies whether
the process could not clean up the auxiliary keys in the keyring
for rotating the binary log master key, or could not clean up
unused binary log encryption keys. You can choose to ignore the
message as the keys are auxiliary keys or no longer in use, or
you can issue ALTER INSTANCE ROTATE BINLOG
MASTER KEY
again to retry the process.
If the server stops and is restarted with binary log encryption
still set to ON
during the binary log master
key rotation process, new binary log files and relay log files
after the restart are encrypted using the new binary log master
key. However, the re-encryption of existing files is not
continued, so files that did not get re-encrypted before the
server stopped are left encrypted using the previous binary log
master key. To complete re-encryption and clean up unused binary
log encryption keys, issue ALTER INSTANCE
ROTATE BINLOG MASTER KEY
again after the restart.
ALTER INSTANCE ROTATE BINLOG MASTER
KEY
actions are not written to the binary log and are
not executed on replication slaves. Binary log master key
rotation can therefore be carried out in replication
environments including a mix of MySQL versions. To schedule
regular rotation of the binary log master key on all applicable
master and slave servers, you can enable the MySQL Event
Scheduler on each server and issue the
ALTER INSTANCE ROTATE BINLOG MASTER
KEY
statement using a CREATE
EVENT
statement. If you rotate the binary log master
key because you suspect that the current or any of the previous
binary log master keys might have been compromised, issue the
statement on every applicable master and slave server. Issuing
the statement on individual servers ensures that you can verify
immediate compliance, even in the case of slaves that are
lagging, belong to multiple replication topologies, or are not
currently active in the replication topology but have binary log
and relay log files.
The
binlog_rotate_encryption_master_key_at_startup
system variable controls whether the binary log master key is
automatically rotated when the server is restarted. If this
system variable is set to ON
, a new binary
log encryption key is generated and used as the new binary log
master key whenever the server is restarted. If it is set to
OFF
, which is the default, the existing
binary log master key is used again after the restart. When the
binary log master key is rotated at startup, the file passwords
for the new binary log and relay log files are encrypted using
the new key. The file passwords for the existing encrypted
binary log files and relay log files are not re-encrypted, so
they remain encrypted using the old key, which remains available
on the keyring.
Nederlandse vertaling
U hebt gevraagd om deze site in het Nederlands te bezoeken. Voor nu wordt alleen de interface vertaald, maar nog niet alle inhoud.Als je me wilt helpen met vertalingen, is je bijdrage welkom. Het enige dat u hoeft te doen, is u op de site registreren en mij een bericht sturen waarin u wordt gevraagd om u toe te voegen aan de groep vertalers, zodat u de gewenste pagina's kunt vertalen. Een link onderaan elke vertaalde pagina geeft aan dat u de vertaler bent en heeft een link naar uw profiel.
Bij voorbaat dank.
Document heeft de 26/06/2006 gemaakt, de laatste keer de 26/10/2018 gewijzigd
Bron van het afgedrukte document:https://www.gaudry.be/nl/mysql-rf-replication-binlog-encryption-key-rotation.html
De infobrol is een persoonlijke site waarvan de inhoud uitsluitend mijn verantwoordelijkheid is. De tekst is beschikbaar onder CreativeCommons-licentie (BY-NC-SA). Meer info op de gebruiksvoorwaarden en de auteur.
Referenties
Deze verwijzingen en links verwijzen naar documenten die geraadpleegd zijn tijdens het schrijven van deze pagina, of die aanvullende informatie kunnen geven, maar de auteurs van deze bronnen kunnen niet verantwoordelijk worden gehouden voor de inhoud van deze pagina.
De auteur Deze site is als enige verantwoordelijk voor de manier waarop de verschillende concepten, en de vrijheden die met de referentiewerken worden genomen, hier worden gepresenteerd. Vergeet niet dat u meerdere broninformatie moet doorgeven om het risico op fouten te verkleinen.