この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
こんにちは。大阪オフィスの林です。
2019年11月20日（水）にAmazon RDS for Oracleの「ALLOWED_LOGON_VERSION_SERVER」および「ALLOWED_LOGON_VERSION_CLIENT」のsqlnet.oraパラメーターをユーザーで変更できるようになりました。公式ページはこちら
本記事では「パラメータの概要」と「簡単な動作検証」をおこないたいと思います！
「ALLOWED_LOGON_VERSION_SERVER」とは？
まずは、Oracleの公式ページより抜粋。※公式ページはこちらから
Oracle Databaseインスタンスへの接続時に認められる最低限の認証プロトコルを設定します
すごく噛み砕いて簡単に説明すると、「インスタンス接続時の認証強度を強くしたり弱くしたりできるよ。」といったところでしょうか。
「ALLOWED_LOGON_VERSION_CLIENT」とは？
そしてこちらも、Oracleの公式ページより抜粋。※公式ページはこちらから
Oracle Databaseインスタンスへの接続時に、サーバーがクライアントの役割を果している場合(データベース・リンクでの接続など)に、クライアントに認められる最低限の認証プロトコルを設定します。
すごく噛み砕いて簡単に説明すると、「データベースリンク接続時の認証強度を強くしたり弱くしたりできるよ。」といったところでしょうか。
検証してみた
今回は「ALLOWED_LOGON_VERSION_SERVER」のパラメータを変えて動作を見ていきたいと思います。
検証準備
検証環境は下図のとおりです。接続元のEC2と接続先のRDS for Oracleを準備しました。「ALLOWED_LOGON_VERSION_SERVER」のパラメータはOracle12以降のパラメータで指定が可能なので、Oracleのエンジンバージョンは「12.1.0.2.v17」としました。
検証内容
「ALLOWED_LOGON_VERSION_SERVER」で設定できるパラメータは「6種類」あります。
| パスワードバージョン | 説明 |
| 12a | Oracle Database 12cリリース12.1.0.2以上の認証プロトコル(最も強力な保護) |
| 12 | Oracle Database 12c リリース12.1の認証プロトコル(デフォルトおよび推奨値) |
| 11 | Oracle Database 11gの認証プロトコル |
| 10 | Oracle Database 10gの認証プロトコル |
| 9 | Oracle9i Databaseの認証プロトコルの場合 |
| 8 | Oracle8i Databaseの認証プロトコルの場合 |
今回の検証では、パスワードバージョンの「10」と「11」しか持たないユーザーでRDS for Oracleに接続を試みます。そして、RDS for Oracleの「ALLOWED_LOGON_VERSION_SERVER」を「10」にした時の挙動と、「12a」にした時の挙動を検証したいと思います。
それでは始めます。
- 「ALLOWED_LOGON_VERSION_SERVER」が「10」の時の動作
- RDS for Oracleに設定されているパラメータグループを確認し、「ALLOWED_LOGON_VERSION_SERVER」を「10」に設定します。
- 接続元のEC2にログインし、下記のコマンドを実行しEC2からRDS for Oracleに接続します。
- 下記のコマンドを実行し、ユーザーのパスワードバージョンを確認します。
- 今回検証で使う「TESTUSER」のパスワードバージョンが「10G」「11G」であることを確認します。
「TESTUSER」に設定されているパスワードバージョンが「10」以上で「ALLOWED_LOGON_VERSION_SERVER」のパラメータも「10」なので特に問題なくログインできました。
- 「ALLOWED_LOGON_VERSION_SERVER」が「12a」の時の動作
- RDS for Oracleに設定されているパラメータグループを確認し、「ALLOWED_LOGON_VERSION_SERVER」を「12a」に設定します。
- 先ほどと同じく、接続元のEC2にログインし、下記のコマンドを実行しEC2からRDS for Oracleに接続します。
- 「ORA-01017: invalid username/password; logon denied」と表示されログインできません。
「TESTUSER」に設定されているパスワードバージョンが「10」「11」で「ALLOWED_LOGON_VERSION_SERVER」のパラメータが「12a」なのでログインすることができませんでした。
注意点
認証の強度を強くするということ自体はとても推奨されることなのですが、強度を高めたがゆえシステムに意図しない影響が出てしまう可能性もあるということを十分に理解しておく必要があります。今回のケースでいうと、アプリケーションで使っているユーザーが「11」や「10」のパスワードバージョンを使っているにも関わらず、強度を高めようと「ALLOWED_LOGON_VERSION_SERVER」の値を「12a」にしてしまった場合、アプリケーションが使えなくなる恐れがあるということです。パラメータを変更する際は十分な検証を行ってから実施しましょう。
全体まとめ
今回のような細かいパラメータでもAWSのサービスは日々アップデートが行われております。些細な情報でも記事を見ていただける方に少しでも有益な情報が届けられるように日々の情報収集を怠らずに技術情報のキャッチアップに励んでいきたいと思います！
4
