ヤフーの IaaS チームに所属する木下です。普段はインフラエンジニアとして IaaS 基盤の開発・構築・運用を担当しています。
ヤフーを傘下に持つZホールディングスは、高度化するサイバーセキュリティの脅威に対応するため、サイバーセキュリティ基本方針を掲げています。
この基本方針の中で、Zホールディングスおよびそのグループ企業は、米国標準技術研究所（NIST）が定めたサイバーセキュリティ基準に準拠したシステムを構築し、サービスを提供すると宣言しています。
タイトルにある NIST SP800-171 はこの「米国標準技術研究所（NIST）が定めたサイバーセキュリティ基準」の一例です。
私が担当する IaaS 基盤でも、このサイバーセキュリティ基本方針に則って NIST SP800-171 への準拠を目指しています。
この記事ではこれまでセキュリティ関連の業務に縁のなかったエンジニアが、「NIST SP800-171 の要件の 1 つである FIPS に対応した暗号化処理を行うために FIPS モードを有効にして自分たちのシステムがこれまで通りに動作するか検証する」という仕事の担当になり、どのような検証を行ったかや、その中で得られた知見などを紹介していこうと思います。
おそらく読者の皆さんのなかにもセキュリティに関する案件の中で顧客や上司から「NIST SP800-171 について調査してほしい」や「システムを NIST SP800-171 に準拠させたい」という相談を受けたことのある方もいらっしゃるかもしれません。
正直なところ、そういった時にいきなり NIST SP800-171 や FIPS 140-2 の原文を読んだところで取っ掛かりがなく、なかなか手を動かし始めるのが難しいと思います。
この記事がそういった方々の一助となれば幸いです。
NIST SP800-171 って？ FIPS 140-2 って？ FIPS モードって？
まず、そもそも NIST SP800-171 や FIPS 140-2、FIPS モードが何なのかについて、簡単に説明します。
NIST SP800-171 とは「NIST（アメリカ国立標準技術研究所）」が定めた「Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations（非連邦政府のシステムおよび組織における CUI の保護）」というタイトルのセキュリティガイドラインです。
CUI とは非連邦政府のシステムおよび組織に存在する「機密指定はされてないが管理対象となる情報」を指し示しています。
これを噛み砕いて説明すると、NIST SP800-171 は民間（「非連邦政府のシステムおよび組織」に該当）が持つ政府によって機密指定されていない情報の中でも、漏えい時にリスクのある情報（管理対象とすべき情報）を保護するために民間のシステムおよび組織が遵守すべきセキュリティガイドライン、ということなります。
これと対となる形で、政府がもつ機密情報を保護するためのセキュリティガイドラインとして「NIST SP800-53」が存在し、NIST SP800-171 は先立って策定されていた NIST SP800-53 がベースとなっています。
セキュリティガイドラインと聞くと、多くの方は ISO 27001（ISMS） のようなものを想像されるかもしれませんが、NIST SP800-171 によって要求されるセキュリティ要件は ISO 27001 によって求められる要件と比較してより広範であることが特徴です。
具体的には、NIST SP800-171 は NIST が公開している CSF（CyberSecurityFramework） でも定義されている「IDENTIFY（特定）」「PROTECT（防御）」「DETECT（検知）」「RESPOND（対応）」「RECOVER（復旧）」の 5 つのセキュリティ標準について一定のレベルを満たすことが求められます。
一方で ISO 27001 は特定と防御には重きを置いていますが、検知から復旧までについては特に定められていません。
その点でも NIST SP800-171 は攻撃と侵入を前提とした、より現代の実情に沿ったセキュリティガイドラインであると言えます。
そのため、米政府の調達に関わらない組織やシステム（= 米国政府の定める CUI を保持しない組織/システム）であっても、NIST SP800-171 に準拠することは現代的なセキュリティ標準を備えた組織/システムであることを担保するために有用な手段です。
現代においては、政府に限らず民間企業も高いセキュリティリスクに晒されていることは連日のセキュリティインシデントに関する報道でも周知のとおりです。
そのため、われわれのようにお客様から大切な情報を預かってビジネスを行う民間企業は、システムと組織が高いセキュリティ標準を備えていることが必然的に求められます。NIST SP800-171 への準拠は会社組織としてそういった高いセキュリティ標準を備えることを目的とした活動の1つです。
ここからは NIST SP800-171 の中で FIPS モードにつながる部分について言及していきます。NIST SP800-171 の推奨セキュリティ要件のうちアクセス管理の章に以下のような記述があります。
3.1.13 Employ cryptographic mechanisms to protect the confidentiality of remote access sessions.
DISCUSSION
Cryptographic standards include FIPS-validated cryptography and NSA-approved cryptography.3.13.11 Employ FIPS-validated cryptography when used to protect the confidentiality of CUI.
DISCUSSION
Cryptography can be employed to support many security solutions including the protection of controlled unclassified information, the provision of digital signatures, and the enforcement of information separation when authorized individuals have the necessary clearances for such information but lack the necessary formal access approvals. Cryptography can also be used to support random number generation and hash generation. Cryptographic standards include FIPSvalidated cryptography and/or NSA-approved cryptography.
出典：NIST SP800-171 Rev. 2（外部サイト）
ここには通信の秘匿性や CUI のデータ保護のためには FIPS 認証された暗号化技術を使う必要があると書いてあります。
FIPS 認証された暗号化技術とはなにかについては同文書の Appendix に記載があります。
FIPS-validated cryptography
A cryptographic module validated by the Cryptographic Module Validation Program (CMVP) to meet requirements specified in FIPS Publication 140-2 (as amended). As a prerequisite to CMVP validation, the cryptographic module is required to employ a cryptographic algorithm implementation that has successfully passed validation testing by the Cryptographic Algorithm Validation Program (CAVP).出典：
出典：NIST SP800-171 Rev. 2（外部サイト）
つまり、FIPS 認証された暗号化技術とは、FIPS 140-2 にある要求を満たすために Cryptographic Module Validation Program（CMVP）によって認証を受けた暗号化モジュールで、その暗号化モジュールは Cryptographic Algorithm Validation Program（CAVP）に合格した暗号化アルゴリズム実装を使っているものになります。
NIST SP800-171 の日本語訳を含む NIST 関連文書へのリンクは以下のサイトに掲載されています。
セキュリティ関連 NIST 文書（外部サイト）
次に FIPS 140-2 について簡単に説明します。
FIPS 140-2 は「SECURITY REQUIREMENTS FOR CRYPTOGRAPHIC MODULES」というタイトルで、レベル 1 〜レベル 4 までのセキュリティレベルが規定され、各セキュリティレベルに応じたセキュリティ要件や暗号化モジュール、物理セキュリティ、OS などに対する要求がまとめられた文書です。
そして、この FIPS 140-2 の各項目は認証された鍵生成方式やハッシュアルゴリズムを利用することを前提としており、その認証されたアルゴリズムは Annex A,C,D にまとめられています。
Annex A: Approved Security Functions
Annex C: Approved Random Number
Annex D: Approved Key Establishment
出典：FIPS 140-2 Security Requirements for Cryptographic Modules（外部サイト）
次に FIPS モードとは何かについて解説していきます。ここでは Red Hat Enterprise Linux 8（RHEL8）を例にとって説明します。
RHEL8 では FIPS モードを有効にすることで、FIPS 認証された暗号化モジュールを利用しているかのチェックが有効化された状態になります。つまり、
- FIPS 認証された暗号化アルゴリズムのみが使えるように制限できる。つまり脆弱な MD5 や DES のようなアルゴリズムの利用を防ぐことが可能になる
- Red Hat 社では Kernel の暗号化 API や OpenSSL のライブラリに対して CMVP を取得しているため、NIST SP800-171 にある”FIPS 認証された暗号化技術を採用する”を満たすことができる
ということを意味します。
Red Hat は CMVP を取得したライブラリと認証番号、そして FIPS 140-2 のどのレベルで認証を受けているかを一覧化して公開しています。
Government Standards #FIPS 140-2（外部サイト）
例えば Red Hat 社がメンテナンス・提供している OpenSSL については#3842で認証されていることがわかります。
少々長い説明になってしまいましたが、NIST SP800-171・FIPS 140-2・FIPS モードの関連性についてご理解いただけたかと思います。以降の章では、いよいよ「NIST SP800-171 に対応するために FIPS モードを有効にして自分たちのシステムがちゃんと動くか確認する」というミッションで遭遇した諸々のトラブルや、それに対して行った対処をご紹介します。
なお、ここまで読み進めていただくと分かる通り、「FIPS モードを有効にする」というアクションはあくまでも NIST SP800-171 で要求されるセキュリティ要件のうちほんの一部を満たすためのものに過ぎません。
NIST SP800-171 に準拠するためにはその他にもさまざまなセキュリティ要件を満たす必要があることにはご注意ください。
FIPS モードを有効化してみる
まずは RHEL8 で FIPS モードを有効化する方法を解説していきます。
FIPS モードを有効化して OS インストールを実施する方法と、インストール後に FIPS モードを有効化する方法の2つがあります。
システムをデプロイ後に FIPS モードを有効にすることは、FIPS 140-2 で許可されない暗号化アルゴリズムが利用されていた際にアプリケーションが正常に動作しなくなるため推奨されていません。
今回の検証では、OS インストール後に FIPS モードを有効化したのでその手順を記載していきます。
手順自体は非常に簡単です。
$ sudo fips-mode-setup --enable
Kernel initramdisks are being regenerated. This might take some time.
Setting system policy to FIPS
Note: System-wide crypto policies are applied on application start-up.
It is recommended to restart the system for the change of policies
to fully take place.
FIPS mode will be enabled.
Please reboot the system for the setting to take effect.
$ sudo grub2-mkconfig -o /etc/grub2.cfg
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.18.0-240.22.1.el8_3.x86_64
Found initrd image: /boot/initramfs-4.18.0-240.22.1.el8_3.x86_64.img
done
$ sudo rebootFIPS モードが有効化されたかは以下の方法で確認が可能です。
fips=1 というブートパラメータが Kernel の起動 Option に渡されていることがわかります。
$ fips-mode-setup --check
FIPS mode is enabled.
$ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-4.18.0-240.22.1.el8_3.x86_64 root=/dev/sda4 ro console=tty0 console=ttyS0,9600 selinux=0 crashkernel=auto nomodeset biosdevname=0 fips=1 boot=UUID=b335c303-6fa3-4c5d-b1be-543217ec62b0次に、実際に FIPS 140-2 で許可されていない暗号化アルゴリズムを利用し、制限がかかっていることを確認してみます。
OpenSSL を利用し、許可されないハッシュアルゴリズムである md5 を利用してハッシュ値を求めようとしてみます。
$ echo "abcd" | openssl md5
Error setting digest
139717332903744:error:060800C8:digital envelope routines:EVP_DigestInit_ex:disabled for FIPS:crypto/evp/digest.c:135:disabled for FIPSという旨でエラーが返ってきています。
このように OpenSSL が FIPS モードを検知して暗号化アルゴリズムの制御を行っていることが見て取れます。
参考：Red Hat FIPS モードへのシステムの切り替え（外部サイト）
FIPS モードが有効化されたサーバーにシステムをデプロイして稼働させてみる
私が所属する IaaS チームは OpenStack をベースとした仮想化基盤の構築・運用が主な業務です。
そこで、FIPS モードを有効化したホスト上で OpenStack をデプロイし、正常稼働するか試してみました。
ここでは、その検証の中で遭遇した FIPS モードによって発生する事象を解説していきます。
FIPS モードではパッケージのインストールさえ一苦労
FIPS モードは暗号化アルゴリズムを制限するものですが、RHEL8 ではこれに加えて RPM パッケージのインストール時に SHA256 で計算されたパッケージおよびヘッダのダイジェスト値が必須となります。
このダイジェスト値の validate はパッケージ管理コマンドのdnf/yumでは、オプション等で無効化することができないため、パッケージ作成時の対応が必須となります。
幸いにも Red Hat 社から供給されるパッケージに関してはこの対応がなされているため特に問題はありません。
ですが、独自にビルドしているパッケージや、OSS コミュニティーが公開しているパッケージの多くはこの SHA256 ダイジェストがなくインストールに失敗する状態でした。
独自にビルドしているパッケージについてはその全てで以下のような対応を行いました。
- ビルド環境を RHEL8/CentOS8 にする
- rpmbuild 時に SHA256 ダイジェストを有効化する
これまでわれわれはビルド環境として CentOS7 を利用してきましたが、CentOS7 にバンドルされる rpm-4.11.3 では SHA256 を利用したダイジェスト値を付与するための Option が利用できませんでした。
SHA256 を利用したダイジェストを付与できるのは rpm-4.14 以降になり、rpm をソースコードからビルドするか rpm-4.14 がバンドルされる RHEL8/CentOS8 を利用する必要がありました。
rpm のリリースノート（外部サイト）
rpm-4.14 以降であれば SHA256 ダイジェストを有効化するのは非常に簡単で、以下のような Option を rpmbuild 時に付与するだけです。
--define "_binary_filedigest_algorithm 8"
--define "_source_filedigest_algorithm 8" // source rpmをビルドしない場合は不要です。rpm-4.14 以上の環境でビルドすると、以下のようにヘッダおよびペイロードの SHA256 ダイジェストが付与されました。
$ rpm --checksig -v neutron-17.0.1.dev72.victoria_yahoo-202109211830.noarch.rpm
neutron-17.0.1.dev72.victoria_yahoo-202109211830.noarch.rpm:
Header SHA256 digest: OK
Header SHA1 digest: OK
Payload SHA256 digest: OKちなみに一部の Q&A サイトでは以下のように Option を表記しているものもあります。
この Option では確かに SHA256 ダイジェストは付与されるのですが、ビルドされたパッケージをdnfコマンドを使ってインストールしようとすると失敗するという問題が発生しました。
--define "_binary_filedigest_algorithm SHA256"
$ rpm --checksig -v ./package-3.4.3-20211119.noarch.rpm
package-3.4.3-20211119.noarch.rpm:
Header SHA256 digest: OK
Header SHA1 digest: OK
Payload SHA256 digest: OK
$ sudo dnf install ./package-3.4.3-20211119.noarch.rpm
~中略~
Error: Transaction failed調べてみるとsha256という誤ったオプションを渡すことで、ダイジェスト値が 000….となっていることがわかりました。
# -define "_binary_filedigest_algorithm SHA256" と誤ったオプションを渡した場合
$ sudo rpm -qp --dump package-3.4.3-20211119.noarch.rpm
/usr/local/bin/script 14360096 1637312683 00000000000000000000000000000000 0100755 root root 0 0 0 X
# -define "_binary_filedigest_algorithm 8" と正しいオプションを渡した場合
$ sudo rpm -qp --dump package-3.4.3-20211119.noarch.rpm
/usr/local/bin/script 14360096 1634260250 86e229816c177053f302c867be88842693eedfb548859ca6360d9bc36af7b76a 0100755 root root 0 0 0 Xrpmbuild コマンドとしてはエラーとして処理が中断されずパッケージの生成まで完了してしまうため、このミスに気づくのはなかなか困難です。
rpmbuild の設計思想はわかりませんが、FIPS モードを有効にするという観点では、将来のバージョンで何らか改善があるといいなと感じました。
次に OSS や Vendor から提供される RPM パッケージの場合ですが、記事執筆時点では多くの場合で SHA256 ダイジェストがついていませんでした。
この場合、取り得る手段としては以下のうちいずれかになると思います。
- rpm コマンドで
--nodigest --nofiledigestオプションをつけてインストールする(https://access.redhat.com/solutions/4460971) - ソースコードからビルドする
後者に関しては手間がかかりすぎるのと、加えて今回は依存関係がないパッケージがほとんどでしたので rpm コマンドによるインストールで対応しました。
余談ですが、Red Hat 社からナレッジベース上でダイジェスト検証を無視するオプションの案内があるので、dnfコマンド側にもそういったオプションを用意してもらえると助かると思いました。
未対応な OSS の例ですが、コンテナオーケストレーションのデファクトスタンダードである Kubernetes では SHA256 ダイジェストに関して以下のIssueは記事公開前に解決されないままクローズされておりました。引き続き Kubernetes のコミュニティが配布しているパッケージには SHA256 ダイジェスト がなくパッケージインストールに失敗する状況ですので、ご注意ください。
Kubernetes のように活発なコミュニティーで開発される OSS であってもまだ未対応である現状からも、OSS コミュニティーでビルドされたパッケージのその多くで SHA256 のダイジェストが対応されていないことは想像に難くありません。
兎にも角にも、これでパッケージのインストールができて、実際にシステムを稼働させる準備がやっと整いました。
FIPS モードによる暗号化アルゴリズムの制限と戦う
システムを稼働させてみると、FIPS モードの本丸である暗号化アルゴリズムの制限が原因のエラーが発生しました。
OpenStack においては以下のようなコードが存在しており、md5 の利用がされていました。
https://github.com/openstack/nova/blob/master/nova/privsep/fs.py#L286
def _get_hash_str(base_str):
"""Returns string that represents MD5 hash of base_str (in hex format).
If base_str is a Unicode string, encode it to UTF-8.
"""
if isinstance(base_str, str):
base_str = base_str.encode('utf-8')
return md5(base_str, usedforsecurity=False).hexdigest()実際にこのコードが呼び出されると以下のようなエラー文が出ますが、これは最初に記載した OpenSSL によって md5 ハッシュを求めるものと同一であることがわかります。
File "/opt/nova/lib64/python3.8/site-packages/nova/privsep/fs.py", line 287, in _get_hash_str
return hashlib.md5(base_str).hexdigest()
ValueError: [digital envelope routines: EVP_DigestInit_ex] disabled for FIPSこちらの問題はバグレポートにあがってはいますが、2021 年 12 月現在ではまだ Master ブランチでも修正が入っておらず、FIPS モードを利用しているユーザーが多くはないことが推測できます。
nova:get_hash_str() not working in FIPS mode（外部サイト）
今回は独自に修正を加え md5 ではなく SHA256 を利用することで回避できました。
いくつかの OSS をチェックしてみましたが、この md5 の利用をやめる PR や Issue が複数見つかりました。
そのため、FIPS 対応という名目で OSS へコミットするチャンスはまだまだ転がっていると言えそうです。
また OpenStack には多くの依存先ライブラリがありますが、OpenSSL を利用しているものは古いバージョンでは FIPS モード対応がされておらずエラーになることがありました。
以下のライブラリでは FIPS モード時に制限される暗号化アルゴリズムを呼び出した場合のエラーハンドリングが不足しており、修正がされているようです。
cryptography internal error with X25519 in FIPS mode (RHEL 8) #5082（外部サイト）
今回、われわれの利用する OpenStack では非常に軽微な修正で済み、晴れて IaaS 基盤のシステムが FIPS 認証された暗号化アルゴリズムのみを利用する状態となりました。
本当にこれで FIPS 認証された暗号化技術を採用できている？
我々の環境において OpenStack やその他のシステムは Kubernetes 上で稼働しており、今回の検証も FIPS モードを有効化したサーバー上に Kubernetes を構築しています。
Kubernetes は FIPS モードが有効化されたサーバー上でも問題なく稼働してくれましたが、実はこの Kubernetes が利用する暗号化モジュールは FIPS 認証されているものではありませんでした。
Kubernetes は Golang で記述されていますが、この Golang が持つ暗号化モジュールは OpenSSL を利用しておらず独自に実装されたもので FIPS 認証はされていないものです。
これは Golang のデフォルトの暗号化モジュールx/cryptoを使っている場合、Kubernetes に限らず Golang で書かれたシステム全般で発生する問題です。
IaaS チームでは、ワンバイナリで動作する点や goroutine の使い勝手の良さからツールやアプリケーションの開発にも積極的に Golang を採用しており、これらすべてが FIPS モード有効化の恩恵を受けられず、FIPS 認証を受けていない暗号化モジュールを使ってしまっているということがわかりました。
FIPS モードは OpenSSL を使って SSL/TLS スタックを実装している場合はその暗号化モジュールを制限することができますが、Golang の crypto の様に OpenSSL を利用せず SSL/TLS スタックを独自実装している場合には FIPS モードによる制限をすり抜けてしまいます。
調査してみると、この問題への対策としては以下のような選択肢が考えられるようです。
- Golang の暗号化モジュールではなく、OSS の OpenSSL のラッパーライブラリを利用する
- OpenSSL の Fork である BoringSSL を利用する
- Red Hat 社が提供する go-toolset を利用する
1つ目の方法は内製のソフトウェアであれば有力な選択肢ですが、外部の OSS の場合はコードの修正が必要になり、upstream に反映されるまでには時間も手間もかかります。
2つ目の BoringSSL は Google がメンテナンスする OSS です。golang/go の Branch として各バージョンに対応する形でメンテナンスされています。
BoringSSL（外部サイト）
golang/go dev.boringcrypto branch（外部サイト）
CMVP も取得しており、FIPS 認証された暗号化モジュールを利用できることになります。
CMVP #3678（外部サイト）
利用方法も簡単で Docker を使ったビルドをしている場合、FROM を修正するだけで他の修正は不要なようです。
A Dockerfile that starts with FROM golang:1.8.3 can switch to FROM goboring/golang:1.8.3b2 (see goboring/golang on Docker Hub) and should need no other modifications.
出典：dev.boringcryptop README.md（外部サイト）
最後に Red Hat 社が提供する go-toolset を利用する方法です。
Go and FIPS 140-2 on Red Hat Enterprise Linux （外部サイト）
記事内では FIPS モードを検知して FIPS 認証済みの暗号化ライブラリを自動的に呼び出してくれるという記載があります。
ビルドツールを go-toolset にするだけで利用ができるため、BoringSSL と同様にコードの修正も不要のようです。
BoringSSL は OSS ではありますが、”OpenSSL のように一般的に利用することを意図しない”、”API の安定性を保証しない”ことを謳っています。
一方で go-toolset の場合は Red Hat 社のサポートがあるのが大きなポイントです。 そのため、適用するプロダクトの要件に応じて最適な選択肢を取る必要があります。
将来的に go のデフォルト暗号化モジュールが FIPS 認証されるか、もしくは Red Hat 社の go-toolset のように FIPS モードを検知してデフォルトの暗号化モジュールから OpenSSL のラッパーライブラリや BoringSSL による実装に切り替わるような仕組みが導入されるかは定かではありません。
ただ、以下の Issue を見ても分かる通り、FIPS 140-2 のような要求に対応するため暗号化モジュールを簡単に切り替えられるようにしたいという議論も進んでいるようです。
golang/go proposal: crypto engines #33281（外部サイト）
Kubernetes に限っては以下のような Issue もあり FIPS-enabled Compilers = BoringSSL/go-toolset への対応を進めているように見えます。（ Kubernetes-sig-security の ML を調査してみましたが関連した議論は確認できずあくまで筆者の憶測です）
kubernetes/kubernetes Change unit test fixtures to be compatible with FIPS-enabled compilers #84561（外部サイト）
Golang で書かれた内製のソフトウェアについては現時点ではどういった対応をするか検討中の段階です。
これは NIST SP800-171 対応が具体的にどういった要件を満たすべきなのか、保存するデータや通信の暗号化をどこまで実施するべきかということがまだ決まっていないためです。
NIST SP800-171 への対応をまさしく今おこなっているという方がいれば同じような状況に置かれていると推測できますが、利用中の言語や OSS がどういった暗号化モジュールを利用しているか、それが CMVP を取得しているかどうかをまずは調べてみるのが良いかと思います。
本項目は以下を参考にしています。
https://kupczynski.info/2019/12/15/fips-golang.html
https://gokulchandrapr.medium.com/go-crypto-and-kubernetes-fips-140-2-fedramp-compliance-66d852ccccd2
おわりに
今回 NIST SP800-171 の準拠に向けて FIPS モードを有効化する方法と、その後実際にシステムをデプロイ・稼働させる中でわかったことについて記載しました。
本記事では、あくまで FIPS モードを有効化し FIPS 認定されていない暗号化アルゴリズムの利用を制限したことにとどまるため、システムが NIST SP800-171 に準拠したという状態にはありません。
また、最後に記載した通り Golang のデフォルトの暗号化モジュールのバイパスもまだ行っていないため正確には FIPS 140-2 準拠ともいえない状態です。これらについては今後社内で他のものと合わせて、足並みをそろえて進めていこうと考えています。
NIST SP800-171 はもともと米国で軍事機密を守るために策定されたものであり、ヤフーのような民間の企業がどういう形で準拠する必要があるか、どういった認証機関によって、どのような方法で認証を受けるかといったことはまだ整備された状態にはありません。
ただ、NIST SP800-171 は PCIDSS のように特定の機密情報を扱うエンジニアにのみ関連があるものではなく、取り扱うデータの機密度に応じて基準は変わる可能性があっても、通信やデータの暗号化という面では全てのエンジニアが関連しうるものだと感じています。
現場のエンジニアとしては NIST SP800-171 や FIPS 140-2 に対する理解を深めることが大切ですが、これらの文書をいきなり読んでもあまりにもスコープが広く、何から始めればいいのか戸惑ってしまうかもしれません。
特にセキュリティという分野については著者を含めて苦手意識があるエンジニアが多いと感じています。
しかしながら実際に手を動かしてみるとさまざまな問題にぶつかり、各 OSS ごとの動向や場合によっては OSS へのコントリビュートのチャンスが生まれました。
NIST SP800-171 をどのように解釈し、システムに対してどのように準拠させるかについて、いちエンジニアが判断を行うことはなかなか難しく社内やチームの方針にも大きく左右されます。
しかし、FIPS 140-2 への準拠ならびに FIPS モードの有効化というかたちであれば、実装上の問題に落とし込みやすく、手のつけやすい領域と言えます。
もし、読者の皆さんも会社や上司から”NIST SP800-171 に準拠させたい”などと言われた場合はまずは FIPS モードの有効化から挑戦してみてはいかがでしょうか？
こちらの記事のご感想を聞かせください。
- 学びがある
- わかりやすい
- 新しい視点
ご感想ありがとうございました
- 木下 裕太
- インフラエンジニア
- ヤフーのIaaSチームでOpenStackやKubernetesの面倒を見ています。最近はソフトウェアロードバランサの開発や運用に新しく挑戦してます。
