#rhba | Explore Tumblr posts and blogs

tak4hir0 · 5 years ago

Link

コンテナイメージのレジストリでは、脆弱性検査の実装が当たり前になっている。企業でKubernetesなどコンテナを使用するにあたって脆弱性対策がどれほど重要なものか理解するために、脆弱性検査や、関連する国際的な標準について整理した。脆弱性（ぜいじゃくせい）とは脆弱性とは、プログラムの動作の不備を悪用される情報セキュリティ上の弱点である。つまり、ソフトウェ��上の問題が原因となって生じた欠陥であり、セキュリティホールとも呼ばれる。当然、ソフトウェア開発者は、脆弱性を産まないように細心の注意を払ってコード開発を進めるが、開発者が利用するオペレーティングシステムのライブラリやパッケージに含まれることもある。そのような事情から、開発者の責任範囲外に原因がある場合も多くある。潜在的な脆弱性を突いた新たなクラッキングの手口が、時間の経過ともに発見される。そのことから、開発当初はコードに脆弱性は無いとされていても、時間経過とともに、新たな手口が発見され、継続的に対策が必要となる。脆弱性が残されたソフトウェアを稼働させ続けると、脆弱性を突いた不正アクセスによって、データ漏洩やサービス停止などのリスクが高まる。例えば、知的財産の流出、お金の財産の不法取得、情報の改ざんなどが発生して、取引上の信用を失うなど、企業が大きな損害を被る結果となる。例えば、インターネットとサーバーを接続する部分のファイアウォールなどで、不要なTCPポートの通信を遮断しているからといって、安心と考えてはいけない。アプリケーションのサービス提供用に外部に公開したポートへのアクセスを悪用して攻撃するためである。別の言い方をすると、ファイアウォールで通信を許可したポートを悪用して不正アクセスを実施するため、ソフトウェアの脆弱性対策は避けることができない。脆弱性が発見されると、ソフトウェアの開発メーカー、オープンソースプロジェクトのコミュニティ、そして、OSSディストリビューターが、対策済みコードやパッケージを準備して配布する。その様なコードやパッケージが、リリースされたら、出来るだけ早い時期に適用して、脆弱性を取り除くことが望ましい。近年はゼロデイ攻撃と呼ばれる脅威が増加する傾向にある。これは、対策済みプログラムを配布するまでの間に攻撃を展開するもので、脆弱性が公開されてから、メーカーやOSSコミュニティが修正プログラムを開発する事も多いため、公表された脆弱性の内容を確認して、対策が完了するまで監視などを強化するなど、注意が必要である。コンテナは、OSのライブラリやパッケージなどから構成されるため、これまで通り脆弱性対策を実施するべきである。脆弱性に関する国際的な標準脆弱性が生じる原因は、様々であり、コードを開発するコミュニティや開発会社が、連携して対策する時に、問題の対象を区別して、問題の重大度、分類などを一致させるために、CVE、CVSS、CWEといった標準が利用される。ここではそれらについて整理する。 CVEとは CVEは、Common Vulnerabilities and Exposures の略で、日本では、「独立行政法人情報処理推進機構セキュリティセンター」によって「共通脆弱性識別子CVE」として扱われている組織のセキュリティを改善するために、ソフトウェアまたはファームウェアの脆弱性の特定とカタログした無料の辞書である。これは 1999年に、連邦政府が後援する研究開発センターが運営するMITREによって開始された、非営利プログラムである。辞書の目的は、既に摘発された脆弱性の識別を標準化することである。つまり、CVE-IDを利用して、複数の技術的な情報源の間で、問題とする脆弱性を識別できる様にすることである。 CVSSとは CVSSは、脆弱性に対するオープンで汎用的な評価手法であり、ベンダーに依存しない共通の評価方法を提供する。CVSSを用いると、脆弱性の深刻度を同一の基準で定量的に比較できる。また、ベンダー、セキュリティ専門家、管理者、ユーザ等の間で、共通の言葉で議論できる。 CWEとは CWEは多種多様な脆弱性の種類を脆弱性タイプとして分類、それぞれCWE識別子（CWE-ID）を付与して階層を体系化する。上位層に近いほど抽象的な脆弱性タイプを表す。反対に、下位層にいくほど具体的な脆弱性タイプや個々の脆弱性を表す。脆弱性タイプは、ビュー（View）、カテゴリー（Category）、脆弱性（Weakness）、複合要因（Compound　Element）の4種類に分類される。参考資料イメージに脆弱性が発見された時の対策コンテナ・イメージに含まれるモジュールには、脆弱性を減らす努力が絶え間なく続けられ、改善されている。一度ビルドしたコンテナ・イメージも時間が経つごとに、脆弱性をもつモジュールが発見される。脆弱性に対する対策は、対策済みモジュールにアップデートしてコンテナ・イメージを再ビルドする事である。信頼の置けるイメージの選択コンテナに含まれるコードは、セキュリティにとって重要である。コンテナのイメージの大部分は、Linux OS、Webサーバー、SQLデータベース、プログラミング言語などのオープン・ソースのパッケージであり、それら各OSSプロジェクトはコンテナのイメージでも配布するため、利用者自身でイメージをビルドする必要も無い。しかし、外部の情報源からコードをダウンロードする際と同様に、コンテナ・イメージの提供元、作成者、そして、内部に悪質なコードが含まれないか確認しなければならない。ベースイメージ、OSパッケージ、プログラム言語のパッケージ、アプリケーションのコードは、コンテナの実行環境にセキュリティの脅威を持ち込まないか？アプリケーションが利用しているライブラリやモジュールなどは、最新であり、脆弱性は無いか？ OSなどのベースイメージ、ミドルウェアは最新を使用しており、脆弱性は無いか？コンテナ・イメージの更新頻度は把握しているか、更新されたことを知る方法はあるか？過去発見された攻撃の�� コンテナに含まれる脆弱性には、どのようなものがあるか理解しておく事は、重要性を理解して対策する上で大切な事である。そこで、過去発見された脆弱性の問題について挙げる。 DROWNと名付けられた脆弱性を悪用すると、攻撃者はTLS暗号化を解除し、パスワード、クレジットカード番号、企業秘密、財務データなどの機密通信を読み取ったり盗んだりできる、2016年3月の公開時に、ある測定では、すべてのHTTPSサーバーの33％が攻撃に対して脆弱であった。その後、修正プログラムの適用が進み、2019年現在、SSL LabsはHTTPSサーバーの1.2％が脆弱であると推定されている。 Dirty COWの脆弱性は、2007年9月からLinuxカーネルに存在し、2016年10月に発見および悪用され。この脆弱性は、Androidを含むすべてのLinuxベースのオペレーティングシステムに影響し非常に深刻。攻撃者はこの脆弱性を悪用してルート権限を取得できる。この脆弱性は、Linuxカーネル内のコピーオンライトのコードに存在する。コピーオンライト(Copy-On-Write)とは、最適化戦略の一つで、大きなデータの複製を要求されても、読み取り（Read)の間は、実際に何もせず複製元のデータを参照する。そして、データの書き換え（Write)が発生した時にコピーして書き換える。もし、複製しても書き換えが発生せずに解放してしまえば、メモリ領域の確保とメモリ上のデータのコピーの処理コストが無駄になってしまう。そこで、前述の様な戦略的な処理によって、処理速度を向上させ、CPU時間を抑えることができる。詳しくは、以下のリンクを参照されたい。 glibcは、「GNU Project」による標準ライブラリlibcの実装である。libcはC言語の標準ライブラリ名であり、システムコールを始めとする基本的な部品を集めたライブラリである。C言語で書かれたプログラムの殆どがlibcを利用している。そして、glibcは、libcを基に大幅に機能を追加したもので、UNIXが持つ特徴を継承したLinuxでは、glibcはLinuxシステムの根幹をなす。glibcはISO C、POSIX、Unix98の各標準にほぼ完全に準拠し、国際化APIも整っている。この様な、過去からの経緯を持った glibc には、これまで数多くの脆弱性が発見されており、次のリンクから、脆弱性のリスト、CVE-ID, CWE-ID, Scoreなどを参照できる。2019年において発見されたものも少なくない事に注目しなければならない。脆弱性データベース脆弱性が発見されると、SE製品を開発や流通する各組織の脆弱性データベースに登録される。さらにMITREでは、CERT/CCやHP、IBM、OSVDB、Red Hat、Symantecなど80を超える主要な脆弱性情報サイトと連携して、脆弱性情報の収集と、重複のない採番に努めている。 CVEにはCVE互換認定の制度があり、脆弱性検査ツールや脆弱性対策情報提供サービス等がCVE識別番号の正確な表示などと、他の機能要件を満たし、MITREへ申請するとCVE互換認定が受けられる。認定を受けると、CVEのロゴが使用でき、認定サイトのリストに掲載される。日本では、JVN、JVN iPedia、MyJVNがCVE互換認定を受けている。 Red Hat の脆弱性データベースは、Red Hat Product Errataにあり、XMLなどのメタ情報として提供される。このデータの分類としてアドバイザリータイプ RHSA に脆弱性対応が含まれる。タイプ RHSA、RHBA、および RHEA アドバイザリーの説明がある。脆弱性スキャン脆弱性スキャナによって、既知の脆弱性を含むパッケージがコンテナ・イメージに含まれるか検査できる。しかし、この様なツールで全ての脆弱性が見つかるわけではないから過信は禁物である。一方、検査の結果で問題がリポートされても、必ずしもただちに対応しなければならない問題ではない。例えば、次の様な理由が考えられる。報告された脆弱性の有する機能を利用していないケースコンテナ化している場合、必要最小のプロセスだけ動かすため、実用上問題が無い脆弱性であるケース Linuxディストリビューター(Red Hatなど）が、バックポートして修正プログラムを提供しているケース誤検知も検知されない事もあり得るので、脆弱性スキャナーを過信せず、依存するパッケージを減らすなど、コンパクトなイメージを作るのが望ましい。そうする事で、脆弱性を含む可能性を減らし、誤検知に時間を費やす時間を減らせる。脆弱性スキャナー様々なオープンソースのスキャナーや商用サービスが有るので、代表的と思われるものについて、以下にまとめる。 Docker Bench for Security Docker Bench for Securityは、Dockerコンテナを本番環境にデプロイするために適切な一般的ベストプラクティスをチェックするスクリプト、検査はすべて自動化され、その内容は CIS Docker Benchmark v1.2.0の影響を受けている。これはコンテナ・イメージで提供されるので、誰でも簡単にdockerコンテナを評価でる。このツールは、Dockerホストで実行して、Dockerホストの構成と稼働中のコンテナなどを検査するもので、次は、Kubernetesのマスターノードで実行した例である。分野ごとにシェルスクリプトが検査して、結果が表示される。 docker/docker-bench-security # ------------------------------------------------------------------------------ # Docker Bench for Security v1.3.4 # # Docker, Inc. (c) 2015- # # Checks for dozens of common best-practices around deploying Docker containers in production. # Inspired by the CIS Docker Community Edition Benchmark v1.1.0. # ------------------------------------------------------------------------------ Initializing Tue Oct 8 00:25:51 UTC 2019 [INFO] 1 - Host Configuration [WARN] 1.1 - Ensure a separate partition for containers has been created [NOTE] 1.2 - Ensure the container host has been Hardened [INFO] 1.3 - Ensure Docker is up to date [INFO] * Using 18.06.1, verify is it up to date as deemed necessary [INFO] * Your operating system vendor may provide support and security maintenance for Docker ## ここから、コンテナに実行状態が検査され、5.6では ssh が動��ていないことが検査されている [INFO] 5 - Container Runtime [PASS] 5.1 - Ensure AppArmor Profile is Enabled [PASS] 5.2 - Ensure SELinux security options are set, if applicable [WARN] 5.3 - Ensure Linux Kernel Capabilities are restricted within containers [WARN] * Capabilities added: CapAdd=[NET_ADMIN] to k8s_kube-flannel_kube-flannel-ds-amd64-jg7jv_kube-system_13b64578-419d-49c6-a8e4-9f75be3e51de_0 [WARN] 5.4 - Ensure privileged containers are not used [WARN] * Container running in Privileged mode: k8s_kube-proxy_kube-proxy-f9xlx_kube-system_19248345-58a8-48f1-b0f5-b9e67e2a1219_0 [PASS] 5.5 - Ensure sensitive host system directories are not mounted on containers [PASS] 5.6 - Ensure ssh is not run within containers [INFO] 6 - Docker Security Operations [INFO] 6.1 - Avoid image sprawl [INFO] * There are currently: 9 images [INFO] 6.2 - Avoid container sprawl [INFO] * There are currently a total of 19 containers, with 17 of them currently running [INFO] Checks: 105 [INFO] Score: 9 参考リンク GitHub docker/docker-bench-security, https://github.com/docker/docker-bench-security Clair (クレア/フランス語読みではクレール) CoreOS (現 Red Hat) によって開発された Clair は、コンテナの脆弱性を静的に検査する。Clair は CNCFのプロジェクトの一つとして活動している。 Clair 主要な機能は以下２つで��る。参考資料に書かれた記事から、Clairは何ができないのかを紹介する。ソフトウェアそのものは解析しない：　Clair はソフトウェアを管理している dpkg や rpm 等のパッケージ管理システムのファイルを解析パッケージ管理されていないソフトウェアの脆弱性を検出しない： Clair が脆弱性を検出するのは、dpkg や rpm 等のパッケージマネージャーでインストールされたものに限られる。例えば、tarファイルをダウンロードして展開してソフトウェアは、スキャン対象にならず脆弱性も検出され無い。未知の脆弱性を検出しない： Clair が検出できるのは、CVE等で公開されている既知の脆弱性のみ。 GUIを提供しない：　Clair はコマンドで起動、設定ファイルはエディタで編集、操作は REST API で実行脆弱性を修正しない： Clair は、脆弱性の修正されたバージョンを教えるが、更新はしない。 Docker Hub に似たパブリックコンテナ・レジストリ Quay.io にも使用されている。また、GitLabで、コンテナの脆弱性検査にも利用でき、設定例 https://docs.gitlab.com/ee/ci/examples/container_scanning.html が公開されている。 Clair のクライアントツールとして、clairctl, klar, reg, clair-scannerがあり、VMwareのHarborもClairクライアントとして動作する。参考リンク Anchore (アンカー) CVEデータとユーザー定義のポリシーを使用してコンテナーのセキュリティを検査するためのツールである。アンカーエンジンは、オープンソースプロジェクトである。アンカーエンジンは、コンテナイメージの監査、分析、認定などの集中サービスを提供する。アンカーエンジンは、Dockerコンテナイメージとして提供され、単独、または Kubernetes や Doccker Swarm などのオーケストレーション環境で、実行できる。そして、ユーザーはRESTful API あるいはアンカーCLI を利用して、アンカーエンジン��操作できる。ユーザーの環境でアンカーエンジンをデプロイすると、コンテナレジストリからイメージがダウンロードされ、ユーザーがカスタマイズ可能なポリシーによって、分析、評価され、セキュリティ、コンプライアンス、およびベストプラクティスの実施がチェックされる。アンカーエンタープライズとアンカーエンジンの違いアンカーエンタープライズは、オープンソースのアンカーエンジンに加えて以下のサポートする。可視化、ポリシー編集、レポート生成、ユーザー管理、プログラミング言語 Python, Ruby, Nodejs, Java のライブラリやパッケージの脆弱性データのフィード APIのRBACサポート脆弱性とパッケージ・メタ情報の全てを供給するサービスレッドハット、Debianなど情報源から脆弱性データの全てを、分析エンジンへ与えるインターネットと接続しない構築商用サポート 24時間/7日間または 8時間x週5日特に、企業向けのLinux利用で、レッドハットを利用する場合に、アンカーエンタープライズは有用と思う。アンカーエンジンのユースケースユーザーの環境にアンカー・エンジンをデプロイすると、コンテナイメージは、レジストリからダウンロードされ、分析される。ユーザーがカスタマイズ可能なポリシーを評価して、セキュリティ、コンプライアンス、およびベストプラクティスの実施チェックを実行する。 CI/CDツールから、アンカーエンジンを RESTful API または、anchor-cli を実行して、コンテナビルド後に、自動的に脆弱性を検査することで、問題の早期発見が可能となる。これは必須のワークフローになると思う。アンカーエンジンによる脆弱性検査の例 Kubernetesで試すより、Docker-Composeは簡単なので、簡易的な手法として実施する。筆者の環境では、アンカーエンジンを1時間くらい動かすとmacOSのDockerエンジンが応答を返さなくなり、Dockerの再起動が必要となる不安定な状態となった。単にメモリの割り当てが足りないと思うけど、本格的に利用するには、Kubernetesクラスタ上で、CICDと一緒に利用するのが望ましいと思われる。まず最初に、Docker-Compose の YAML をコピーするためのディレクトリを作成して、アンカーエンジンのコンテナを実行して、コンテナの内部から、ローカルに Docker-Compose のYAMLファイルをコピーする。そして、使用済みのコンテナを削除する。 Status: Downloaded newer image for anchore/anchore-engine:latest docker.io/anchore/anchore-engine:latest $ docker create --name ae docker.io/anchore/anchore-engine:latest 47b152d2427862c5ad9c7853b0e32a58e0ae5040224531af7de2e086182cdf65 $ docker cp ae:/docker-compose.yaml ~/work3/anchor/docker-compose.yaml $ docker rm ae ae docker-composeコマンドでアンカーエンジンのシステムを起動する。 $ ls docker-compose.yaml $ docker-compose pull Pulling anchore-db ... done Pulling engine-catalog ... done Pulling engine-analyzer ... done Pulling engine-policy-engine ... done Pulling engine-simpleq ... done Pulling engine-api ... done $ docker-compose up -d Creating network "anchor_default" with the default driver Creating volume "anchor_anchore-db-volume" with default driver Creating volume "anchor_anchore-scratch" with default driver Creating anchor_anchore-db_1 ... done Creating anchor_engine-catalog_1 ... done Creating anchor_engine-simpleq_1 ... done Creating anchor_engine-api_1 ... done Creating anchor_engine-analyzer_1 ... done Creating anchor_engine-policy-engine_1 ... done 起動を確認しておく。 8228/tcp anchor_engine-catalog_1 /docker-entrypoint.sh anch ... Up (health: starting) 8228/tcp anchor_engine-policy-engine_1 /docker-entrypoint.sh anch ... Up (health: starting) 8228/tcp anchor_engine-simpleq_1 /docker-entrypoint.sh anch ... Up (health: starting) 8228/tcp imac:anchor maho$ docker-compose exec engine-api anchore-cli system status Service analyzer (anchore-quickstart, http://engine-analyzer:8228): up Service policy_engine (anchore-quickstart, http://engine-policy-engine:8228): up Service simplequeue (anchore-quickstart, http://engine-simpleq:8228): up Service apiext (anchore-quickstart, http://engine-api:8228): up Service catalog (anchore-quickstart, http://engine-catalog:8228): up Engine DB Version: 0.0.11 Engine Code Version: 0.5.0 アンカーエンジン起動直後は、脆弱性データを持っていないので、ダウンロードが始まる。今回は簡単に試すために、docker-composeで立ち上げたコンテナから、anchore-cliコマンドを実行する簡易的な手段を選ぶ。 $ docker-compose exec engine-api anchore-cli system feeds list Feed Group LastSync RecordCount nvdv2 nvdv2:cves None 0 vulnerabilities alpine:3.10 2019-10-08T14:48:49.756530 1485 vulnerabilities alpine:3.3 None 0 vulnerabilities alpine:3.4 None 0 vulnerabilities alpine:3.5 None 0 vulnerabilities alpine:3.6 None 0 筆者の環境で、約1時間で脆弱性データのダウンロードが完了した。このアンカーエンジンは無料版なので、RHELなど、サポートにサブスクリプション契約が必要なものが含まれない。CentOS, Debian, Ubuntu などに限られることが解る。 imac:anchor maho$ docker-compose exec engine-api anchore-cli system feeds list Feed Group LastSync RecordCount nvdv2 nvdv2:cves None 0 vulnerabilities alpine:3.10 2019-10-08T14:48:49.756530 1485 vulnerabilities alpine:3.3 2019-10-08T14:48:55.240451 457 vulnerabilities alpine:3.4 2019-10-08T14:49:02.902517 681 vulnerabilities alpine:3.5 2019-10-08T14:49:12.996332 875 vulnerabilities alpine:3.6 2019-10-08T14:49:25.639193 1051 vulnerabilities alpine:3.7 2019-10-08T14:49:40.640122 1253 vulnerabilities alpine:3.8 2019-10-08T14:49:56.309720 1335 vulnerabilities alpine:3.9 2019-10-08T14:50:14.736434 1428 vulnerabilities amzn:2 2019-10-08T14:50:25.915568 224 vulnerabilities centos:5 2019-10-08T14:50:59.159077 1325 vulnerabilities centos:6 2019-10-08T14:51:37.040844 1355 vulnerabilities centos:7 2019-10-08T14:52:13.030123 898 vulnerabilities centos:8 2019-10-08T14:52:18.913897 76 vulnerabilities debian:10 2019-10-08T14:56:14.448113 21268 vulnerabilities debian:11 2019-10-08T14:59:53.728597 17984 vulnerabilities debian:7 2019-10-08T15:03:29.329481 20455 vulnerabilities debian:8 2019-10-08T15:07:37.040421 22575 vulnerabilities debian:9 2019-10-08T15:11:44.730702 21438 vulnerabilities debian:unstable 2019-10-08T15:16:01.736180 22314 vulnerabilities ol:5 2019-10-08T15:16:44.124014 1239 vulnerabilities ol:6 2019-10-08T15:17:39.418314 1456 vulnerabilities ol:7 2019-10-08T15:18:28.390050 1038 vulnerabilities ol:8 2019-10-08T15:18:32.804512 68 vulnerabilities ubuntu:12.04 2019-10-08T15:21:09.029691 14948 vulnerabilities ubuntu:12.10 2019-10-08T15:22:05.408912 5652 vulnerabilities ubuntu:13.04 2019-10-08T15:22:39.667026 4127 vulnerabilities ubuntu:14.04 2019-10-08T15:25:51.886441 19685 vulnerabilities ubuntu:14.10 2019-10-08T15:26:41.300071 4456 vulnerabilities ubuntu:15.04 2019-10-08T15:27:41.424339 5831 vulnerabilities ubuntu:15.10 2019-10-08T15:28:49.917239 6513 vulnerabilities ubuntu:16.04 2019-10-08T15:32:06.318408 16802 vulnerabilities ubuntu:16.10 2019-10-08T15:33:23.158525 8647 vulnerabilities ubuntu:17.04 2019-10-08T15:34:40.605672 9157 vulnerabilities ubuntu:17.10 2019-10-08T15:35:45.769257 7935 vulnerabilities ubuntu:18.04 2019-10-08T15:37:20.472998 11054 vulnerabilities ubuntu:18.10 2019-10-08T15:38:27.803139 8392 vulnerabilities ubuntu:19.04 2019-10-08T15:39:24.065979 7593 アンカーエンジンによる脆弱性検査脆弱性検査したいイメージを、レジストリから追加する。これも簡易的にコンテナ内で anchor-cli を実行する。 $ docker-compose exec engine-api anchore-cli image add docker.io/maho/web-nginx:11 Image Digest: sha256:e393398ce2cb232ee15104079dc5fe91cbd985ca013a4898816b628fbce7d9b8 Parent Digest: sha256:e393398ce2cb232ee15104079dc5fe91cbd985ca013a4898816b628fbce7d9b8 Analysis Status: not_analyzed Image Type: docker Analyzed At: None Image ID: 359128981386754efdc61ed716b4f69544725e0554388d8046f1ceac2ae27062 Dockerfile Mode: None Distro: None Distro Version: None Size: None Architecture: None Layer Count: None Full Tag: docker.io/maho/web-nginx:11 Tag Detected At: 2019-10-08T22:21:27Z イメージのリストを表示する。事前に、debian:7とdebian:8も追加していたので３つ表示された。analyzedと表示され、脆弱性検査が完了していることが読み取れる。 $ docker-compose exec engine-api anchore-cli image list Full Tag Image Digest Analysis Status docker.io/library/debian:7 sha256:81e88820a7759038ffa61cff59dfcc12d3772c3a2e75b7cfe963c952da2ad264 analyzed docker.io/library/debian:8 sha256:9bdad8283833c08697a4de37c6eb0e281598c0e47d09d8b3e1113b7137e27e38 analyzed docker.io/maho/web-nginx:11 sha256:e393398ce2cb232ee15104079dc5fe91cbd985ca013a4898816b628fbce7d9b8 analyzed 筆者が数ヶ月前にビルドしたNGINXのコンテナイメージの脆弱性検査のレポートをリストしてみる。脆弱性IDと詳細を説明したURLが表示されている。これは確かに有用なツールだ。コマンドとして脆弱性レポートを取れるのと、anchore-cli image wait とすることで、イメージの登録後、脆弱性検査が完了するまで、待機させることができるので、Jenkins の設定に追加することも簡単だ。 $ docker-compose exec engine-api anchore-cli image vuln docker.io/maho/web-nginx:11 all Vulnerability ID Package Severity Fix CVE Refs Vulnerability URL CVE-2018-20843 libexpat1-2.2.0-2+deb9u1 High 2.2.0-2+deb9u2 https://security-tracker.debian.org/tracker/CVE-2018-20843 CVE-2019-11068 libxslt1.1-1.1.29-2.1 High 1.1.29-2.1+deb9u1 https://security-tracker.debian.org/tracker/CVE-2019-11068 CVE-2019-1547 libssl1.1-1.1.0j-1~deb9u1 Low 1.1.0l-1~deb9u1 https://security-tracker.debian.org/tracker/CVE-2019-1547 CVE-2019-11038 libgd3-2.2.4-2+deb9u4 Medium 2.2.4-2+deb9u5 https://security-tracker.debian.org/tracker/CVE-2019-11038 CVE-2019-13117 libxslt1.1-1.1.29-2.1 Medium 1.1.29-2.1+deb9u1 https://security-tracker.debian.org/tracker/CVE-2019-13117 CVE-2019-13118 libxslt1.1-1.1.29-2.1 Medium 1.1.29-2.1+deb9u1 https://security-tracker.debian.org/tracker/CVE-2019-13118 CVE-2019-13627 libgcrypt20-1.7.6-2+deb9u3 Medium None https://security-tracker.debian.org/tracker/CVE-2019-13627 CVE-2019-1543 libssl1.1-1.1.0j-1~deb9u1 Medium 1.1.0k-1~deb9u1 https://security-tracker.debian.org/tracker/CVE-2019-1543 CVE-2019-1563 libssl1.1-1.1.0j-1~deb9u1 Medium 1.1.0l-1~deb9u1 https://security-tracker.debian.org/tracker/CVE-2019-1563 CVE-2019-15903 libexpat1-2.2.0-2+deb9u1 Medium 2.2.0-2+deb9u3 https://security-tracker.debian.org/tracker/CVE-2019-15903 CVE-2019-5094 e2fslibs-1.43.4-2 Medium 1.43.4-2+deb9u1 https://security-tracker.debian.org/tracker/CVE-2019-5094 CVE-2019-5094 e2fsprogs-1.43.4-2 Medium 1.43.4-2+deb9u1 https://security-tracker.debian.org/tracker/CVE-2019-5094 CVE-2019-5094 libcomerr2-1.43.4-2 Medium 1.43.4-2+deb9u1 https://security-tracker.debian.org/tracker/CVE-2019-5094 CVE-2019-5094 libss2-1.43.4-2 Medium 1.43.4-2+deb9u1 https://security-tracker.debian.org/tracker/CVE-2019-5094 CVE-2005-2541 tar-1.29b-1.1 Negligible None https://security-tracker.debian.org/tracker/CVE-2005-2541 CVE-2007-5686 login-1:4.4-4.1 Negligible None https://security-tracker.debian.org/tracker/CVE-2007-5686 参考資料 OpenSCAP 最初に、OpenSCAPの背景となるSCAPを簡単に説明する。米国政府省庁の情報セキュリティ対策への要求として、情報システムのセキュリティを強化することを義務付けた法律FISMA（Federal Information Security Management Act：連邦情報セキュリティマネジメント法）が2002年に施行された。これを含め関連の法遵守のため、OSなどの設定作業を手作業で行うと、設定ミスや設定者のセキュリティ知識の程度、判断の相違などからセキュリティが損なわれる可能性がある事などから、作業を自動化する事が効率牲・有効性の観点から求められた。このようなことから、NIST（National Institute of Standards and Technology）において、情報セキュリティ対策の自動化と標準化を目指したSCAP（Security Content Automation Protocol：セキュリティ設定共通化手順）の開発が行われた。現在、SCAPは次の6つの標準仕様から構成される。 OpenSCAPとは、システム管理者と監査者がセキュリティベースラインの評価、測定、および実施を支援する複数のツールである。このツールは、上記の標準仕様に基づくように開発された。 SCAP関連のツールは、(RHEL7では)以下4種が提供され、OpenSCAPもその一つであある。Dockerコンテナを検査するツールoscap-dockerは、oscapの機能を使用している。 SCAP Workbench ： scap-workbench GUIツールは、システム上で、構成スキャンと脆弱性スキャン、そして、セキュリティーレポートの生成を実行できる。 OpenSCAP ： oscap コマンドは、ローカルシステムの構成スキャンと脆弱性スキャンを実行、セキュリティーコンプライアンスを検証、評価に基づいてレポートとガイドを生成する。 Script Check Engine (SCE) ： SCE は SCAPプロトコルの拡張機能であり、管理者がこれを使用して Bash、Python、Ruby などのプログラム言語を使って、セキュリティーチェックのコードを記述できる。SCEは、openscap-engine-sce パッケージで提供される。 SCAP Security Guide (SSG) ： The scap-security-guide パッケージは、Linux システム向けの最新のセキュリティ・ポリシーコレクションを提供する。このガイダンスは、セキュリティ強化に関する実践的なアドバイスのカタログで、該当する場合は、法規制要件に関連付けられる。 oscap-dockerの使用例最初に、Security compliance of RHEL7 Docker containersの手順に沿って、環境をセットアップする。ローカルに保存されたコンテナイメージのリストを表示する。 [root@rhel7 vagrant]# docker images REPOSITORY TAG IMAGE ID CREATED SIZE registry.access.redhat.com/rhel7 latest bd0240457182 5 weeks ago 205 MB docker.io/hello-world latest fce289e99eb9 9 months ago 1.84 kB イメージ名を指定して、脆弱性レポートを作成する。結果は --report cve-report.html にHTML形式で出力される。 [root@rhel7 vagrant]# oscap-docker image-cve registry.access.redhat.com/rhel7 --results cve-results.xml --report cve-report.html 次のスクリーンショットは、--report cve-report.htmlの指定により出力されたHTMLファイルをブラウザで表示したものである。こちらのオプションでは、セキュリティ評価を記述したOVALに従ってイメージを検査する。ここで指定したOVALでは、United States Government Configuration Baseline (USGCB / STIG) などのセキュリティ設定が遵守されていることをチェックする。 [root@rhel7 vagrant]# oscap-docker image registry.access.redhat.com/rhel7 oval eval --results oval-results.xml --report report.html /usr/share/xml/scap/ssg/content/ssg-rhel7-oval.xml ベースイメージにRHELを使用してない場合は、検査することができない。RHELのコンテナのベースイメージには、OpenSCAPに検査に必要なメタ情報が含まれるためと思われる。 docker.io/maho/web-nginx:11 is not based on RHEL 参考資料 Dagda 既知の脆弱性、トロイの木馬、ウイルス、マルウェア、その他のDockerイメージ/コンテナ内の脅威の静的分析を実行し、異常なアクティビティを検出するためにDockerデーモンと実行中のDockerコンテナを監視するツールである。 Dagdaの内容を読むと、静的な脆弱性検査と、実行中コンテナの不審な動作にも対応する、大変優れたツールと思われる。しかし、出力はJSON形式で、Pythonのコードをコマンドラインから実行する。Dagdaは、ツールと呼ぶよりも、ソフトウェア部品と考えた方が良さそうだ。その後、Dagdaは、実行中のDockerコンテナの不審な振る舞いを監視するためにSysdig Falco に統合されている。さらに、CNCFの Sand Box プロジェクト Falco として登録された。このDagdaは、脆弱性データとして、CVE（Common Vulnerabilities and Exposures）、BID（Bugtraq ID）、RHSA（Red Hat Security Advisories）、RHBA（Red Hat Bug Advisories）、そして、攻撃的セキュリティデータベース Exploit Database を MongoDBにインポートする。攻撃的セキュリティとは、攻撃者がどのような脆弱性を突いて攻撃をしかけてくるかを想定し、未然の策を講じておく、積極的な対策のことである。次��、Dagdaは、OSパッケージやプログラミング言語の依存関係など、Dockerイメージにインストールされたソフトウェアに関する情報を取得し、MongoDBに保存された脆弱性情報と照合して、各製品とそのバージョンがないかどうかを確認する。Dagdaは、ClamAVをウイルス対策エンジンとして使用して、トロイの木馬（trojans)、ウイルス、マルウェア、およびDockerイメージとコンテナに含まれるその他の悪意のある脅威を検出する。 Dagdaは複数のコンテナベースイメージをサポート Red Hat/CentOS/Fedora Debian/Ubuntu OpenSUSE Alpine Dagdaは、複数の依存関係を分析するために、OWASP依存関係チェック+ Retire.jsに依存する。 java python nodejs js ruby php さらなる発展として、Falco Operator として、Kubernetesの実行中のアプリケーションの不審な振る舞いを検知するためのリアリタイム監視オペレータとして開発が進んでいる。参考資料 * Dagda, https://github.com/eliasgranderubio/dagda * Falco, https://falco.org/ * Falco operator, https://github.com/falcosecurity/falco-operator * Kubernetes に Falco を展開してアプリケーションの挙動をモニタリングする,https://medium.com/@makocchi/falco-with-kubernetes-ja-1e2c045b3840 Microscanner と Trivy Microscannerはインターネット越しに利用できるサービスなので、インストールしたり環境を作らなくても即に利用できる、TrivyはOSSで、どちらもAquaが提供する。 MicroScannerは、開発者向けの無料の画像脆弱性スキャナであり、Aquaのクラス最高の商用スキャナーと同じ脆弱性データベースを使用して最高の結果が得られるとのこと。 MicroScannerとAquaの商用製品との主な違いは、Dockerfile内で指定されたビルドステップ中に実行されること。 ADD https://get.aquasec.com/microscanner / RUN chmod +x microscanner RUN MicroScannerが重大度の高い脆弱性を検出すると、ゼロ以外の終了コードを返し、イメージのビルドを失敗停止させる。そのため、CICDのパイプラインに組み込み安く、脆弱性検査結果もビルドログに出力される。そして、同じAquaのGitHubリポジトリから、コンテナー用のシンプルで包括的な脆弱性スキャナ Trivyがある。この開発者は日本人。このソフトウェアは、OSパッケージ（Alpine、RHEL、CentOSなど）およびアプリケーションの依存関係（Bundler、Composer、npm、yarnなど）の脆弱性を検出。バイナリをインストールして、コンテナのイメージ名を指定してスキャンするだけで、簡単に利用できる。以下の例は、コンテナイメージ python:3.4-alpineをスキャンする例である。 $ trivy python:3.4-alpine 参考資料 Twistlock Twistlockはインターネット越しに利用できる商用サービス。各社クラウドサービスと連携した利用が想定され、AWS,Azure,GCPに加えて、IBM Cloud のサービスとも連携して利用可能。もちろん、Kubernetes と Docker、OpenShiftにも対応する優れたセキュリティ対策サービス。デプロイからランタイムの範囲をカーバーするとのこと。そして、IBM Cloud セキュリティ・アドバイザーと連携して、問題を未然に防ぐ役割を果たす。今年、Twistlockは、パロアルトネットワークスに買収された。 2019年7月9日 -パロアルトネットワークス（NYSE：PANW）、世界的なサイバーセキュリティのリーダー、それはツイストロックの買収を完了したことを発表しま��た、コンテナ・セキュリティのリーダー、そのプリズマ™クラウドのセキュリティを拡張します戦略。この買収により、ライフサイクル全体を通じて今日の最新のアプリケーションを保護する同社の能力がさらに向上し、組織は安全で信頼性が高くスケーラブルなイノベーションを提供できます。参考資料その他 Notary Notaryは、Dockerイメージの署名フレームワークのデファクトスタンダードで、Dockerはオープンソース化して CNCF へ寄贈(2017) Grafaes(ギリシャ語でスクライブ) Grafaesは、IBMとGoogleによって開発された。ソフトウェアサプライチェーンを監査および管理するための統一された方法を提供するOSSのアーティファクトメタデータAPIであり、IBM Vulnerability Advisor に採用されている。 Banyanops Collector Banyanopsコレクタは、コンテナイメージの内容を見るためのフレームワーク Cilium (スゥリウム)) Ciliumは、BPFとLinuxカーネル技術によって、アプリケーションコードやコンテナ構成を変更せずにセキュリティポリシーを適用および更新できる。CoreOS(現 Red Hat)によって開発された。コンテナビルド時に、脆弱性スキャンを実施 CICDパイプラインの中に、脆弱性スキャンを組み込むことで、問題を早期に発見して、対策することができる。ビルドステップが完了したら、脆弱性スキャンを実行して、レポートする。重大な脆弱性が発見された場合は、次のテストステップに進めることなく、脆弱性対策を実施する。前述のスキャナーの中にも、CLIから脆弱性検査を実行できて、重大な脆弱性が発見されると終了コードによってステップを異常終了できるものがある。参考資料上記の参考資料と重複もあるが、記事を書くにあたり参考にした資料なので、残しておきたいので以下に列挙する。 Container Scanning, https://kubedex.com/container-scanning/ Detecting and blocking vulnerable containers in Kubernetes (deployments), https://banzaicloud.com/blog/anchore-image-validation/ Clair によるコンテナ・イメージの脆弱性検出, https://www.ogis-ri.co.jp/otc/hiroba/technical/clair/part1.html コンテナの脆弱性をスキャンするCoreOSの「Clair」, https://japan.zdnet.com/article/35080056/ Clairで、Dockerイメージの脆弱性スキャンを試す,https://kazuhira-r.hatenablog.com/entry/2019/01/12/224956 Dockerコンテナに対する脆弱性スキャン機能をRed Hatが提供。サードパーティ製品によるスキャンも可能,https://www.publickey1.jp/blog/16/dockerred_hat.html 気軽に使えるContainerの脆弱性スキャンツール Trivy を試してみた,https://tech.recruit-mp.co.jp/infrastructure/continuous-integration-vulnerability-detection-tool-trivy/ 最近話題のコンテナ脆弱性ツール「Trivy」を試してみた, https://dev.classmethod.jp/etc/trivy_poc/ CIで使えるコンテナの脆弱性スキャナ,https://qiita.com/knqyf263/items/dc179f9223fc31b5a51c Container Registry の脆弱性スキャンで安全な CI/CD パイプラインを、https://cloud.google.com/blog/ja/products/gcp/guard-against-security-vulnerabilities-with-container-registry-vulnerability-scanning Red Hat、新しいスキャニング機能でよりセキュアなコンテナを実現、https://www.redhat.com/ja/about/press-releases/rhjapan-red-hat-delivers-more-secure-containers-new-scanning-capability パッチおよび脆弱性管理プログラムの策定、https://www.ipa.go.jp/files/000025330.pdf Top 7 Kubernetes security tools to harden your container stack,http://techgenix.com/kubernetes-security-tools/ Kubernetesのセキュリティについて整理してみた件,https://qiita.com/mamomamo/items/1651b8f9e44938c0de15 エンジニアなら脆弱性情報を読めるようになろう,https://adtech.cyberagent.io/techblog/archives/4025 コンテナ・セキュリティの 10 大要素,https://www.redhat.com/cms/managed-files/cl-container-security-openshift-cloud-devops-tech-detail-f7530kc-201705-a4-ja.pdf コンテナによるレガシーシステムのモダナイゼーション,http://www.projectatomic.io/blog/ Configure a Security Context for a Pod or Container,https://kubernetes.io/docs/tasks/configure-pod-container/security-context/ Kubernetesに深刻な脆弱性,https://japan.zdnet.com/article/35129584/ Kubernetesを監視, https://www.elastic.co/jp/what-is/kubernetes-monitoring OpenShift4と新しいKubernetesエコシステム, http://people.redhat.com/kfujii/cc2019/R305S2_RHC_2019_OpenShift%204%E3%81%A8%E6%96%B0%E3%81%97%E3%81%84Kubernetes%E3%82%A8%E3%82%B3%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0.pdf?fbclid=IwAR3qpeC1h4M9wP_326RFd2yPWN2F4dRTHfpdr9TTW7xwDgihfThbpczePAA Falco Operator, https://operatorhub.io/operator/falco Kubernetes に Falco を展開してアプリケーションの挙動をモニタリングする,https://medium.com/@makocchi/falco-with-kubernetes-ja-1e2c045b3840 10+ top open-source tools for Docker security, https://techbeacon.com/security/10-top-open-source-tools-docker-security

#Qiita

0 notes

oom-killer · 6 years ago

Text

2018/10/22-28

*ISUCON8 本戦にて優勝してきました #isucon https://blog.whywrite.it/2018/10/22/isucon8-final/

*ISUCON予選突破を支えたオペレーション技術 https://blog.yuuk.io/entry/web-operations-isucon >ISUCONでやることは、与えられたウェブアプリケーションをとにかく >高速化することだけです。高速化と一口に言っても、複数のゴールが >あります。ウェブアプリケーションの場合は以下のようなものでしょう。 > > - レスポンスタイムが小さい > - スループット (req/s) が大きい > - CPUやメモリなどリソース消費量が小さい

>とはいっても、リトルの法則により、安定した系において、レスポンス >タイムが小さくなれば、スループットは向上するため、レスポンスタイ >ムとスループットは相関します。 > >リソース消費量の改善は、レスポンスタイムに寄与するというよりは、 >サーバ管��にまつわる人的または金銭的なコストを下げることに寄与し >ます。例えばメモリが余っているのに、メモリ使用量を削減しても、 >レスポンスタイムには影響しません。ただし、そういった無駄を省く >ことで、アプリケーションの処理効率がよくなり、結果としてレスポン >スタイムが良くなることはあります。

>OS・ミドルウェアのチューニングが劇的な加点要素になることはあまり >ありません。そのレイヤのチューニングはリソース消費量を小さくする >ことに寄与することが多いためです。

*トーバルズ氏、Linux開発コミュニティーのトップに復帰 https://japan.zdnet.com/article/35127400/

*東証がシステム障害の原因公表、メリルリンチがIPアドレスを重複使用 https://tech.nikkeibp.co.jp/atcl/nxt/news/18/03092/ >東証は9日時点で、ある証券会社のシステムからarrowheadにシステム >電文が大量送信されたことで、4つのうち1つの接続経路に障害が発生 >したと公表している。

>メリルリンチ日本証券は9日朝、同一IPアドレスのサーバーを2台立ち >上げた。このうち1台と東証側の接続装置が通信を確立させるシステム >電文をやり取りし、通信を確立した。そこにもう1台の同じアドレスを >持ったサーバーから通信を確立させるシステム電文が割り込む形で送ら >れた。 > >システム電文は管理��号で連続的なやり取りの整合性を確認している >という。この連番に��整合が生じたため、サーバー側からシステム電文 >の再送要求が出された

>10月6～8日の3連休でメリルリンチと東証は接続テストをしていたが、 >新設したサーバーだけを立ち上げてテストしたため、事前に発見でき >なかったという。

>異常な通信が発生しても1つの通信系統をすべて止めないようなシステ >ムの設定を検討する。また同一のIPアドレスやポートの申請を禁止する、 >極めて短い間隔での電文を禁止するなど、接続仕様を改定して障害の >原因になり得る要素を取り除く。証券会社がサーバーを新設する際の >確認事項も具体化する。

*1987年に手動でディープラーニングをしていた驚異の麻雀ゲームがあった──アキバ通いのパソコン少年がゲームアーツを創業──宮路洋一氏にゲームAIの核を聞く【聞き手：三宅陽一郎】 http://news.denfaminicogamer.jp/interview/181024/2 >つまりやっていることはディープラーニングも同じなんですよね。あれの >本質って、何回もシミュレーションすることなので、確率論であって確実 >な正解を導くものじゃない。ただ、そうした確率的な揺らぎの部分で予想外 >の結果が出たときに、その面白さを機械は評価できないんです。その部分 >は、人間の感性で判断していくわけですよ。 > >そのとき、「じゃあこのゲームはどんな体験をさせてくれるのか」という >ことはつねに考えています。それはこの業界に足を踏み入れたときから >そう。だからテストプレイで感じたことがいちばん重要。スゴく時間が >かかりますが、面白くするには、もうそれだけですね。

>“クソゲー”の基準ってどこにあるのでしょう？ > >　やっぱり、「なぜやられているか」が納得できるか否かですね。だから、 >ゲーム体験で絶対に重要なのは「あー、俺なんでこんなミスしちゃったん >だろう」と思うフィードバックがプレイヤーにもたらされることなんです。

>僕は汎用的にいろいろなものに使えるAIのようなものって、基本的にまだ >使えないものだと思っています。むしろ特化型にしたほうがゲームには向 >いていますよね。

>最近、AIを勉強してからゲーム開発に入ってくる人が多いのですが、そこ >で自分が学んだ技術を使おうとしちゃうことが多いんですよね。本当は、 >技術とゲームデザインのバランスが大事なのですが、いまその両方につい >て深く解っている人は本当にいないんです。

>やっぱり分業制になっちゃっているからですよね。するとコミュニケーシ >ョンがうまくいかず、エンジニアとゲームデザイナーが喧嘩しちゃうこと >も多いんです。

>ギャンブルって、その人の生きかたや考えかたが如実に表れるのが面白い >んですよ。

*ISUCON8 本選問題の解説と講評 http://isucon.net/archives/52598691.html >最新のtradeを求めるために下記のクエリを実行していました。 >SELECT * FROM trade ORDER BY id DESC > >実際に「ORMで自動的にLIMIT 1が追加されることに慣れていたため、 >生のSQLを扱うときにもLIMIT 1を指定しなかった」という問題に何度 >か直面したことがありました。

>しかし、仕様には「infoに返すデータは原則1秒以内に反映する必要が >ある」という記載があり、裏を返すと「infoに返すデータは原則1秒間 >キャッシュしても良い」ということになるため、このクエリにとらわ >れずにキャッシュしてしまえば、1秒に1回ほどしか実行されないもの >となるためクエリ自体の対策は不要だったかもしれません。

*Red Hat Enterprise Linuxの修正はどのように出荷されるか https://speakerdeck.com/moriwaka/red-hat-enterprise-linuxfalsexiu-zheng-hadofalseyounichu-he-sareruka?slide=13 >一部のセキュリティ監査ツールはソフトウェアのバージョン番号だけを >参照して問題を報告します。報告された問題はすでに Red Hat製品では >対策済みである場合があります。

>修正が作成・出荷される期間は >ライフサイクルポリシーにより定められてます。 > - 例：RHEL5/6/7 では初期リリースから10年間

>アドバイザリの種別とID > - セキュリティ修正：RHSA > - バグ修正　　　　：RHBA > - 機能拡張　　　　：RHEA

*Amazonプライムデーのサーバ障害、AmazonがOracleからAurora DBに乗り換えたのが原因ではない。Amazon CTOがCNBCの報道を否定 https://www.publickey1.jp/blog/18/amazonamazonoracleaurora_dbamazon_ctocnbc.html >チームはAuroraとOracleがセーブポイントを異なる方法で処理することを >知っていたにもかかわらず、問題となるアプリケーションは大量のセーブ >ポイントを作成してしまった。これによって一時的にデータベースは非常 >に遅くなり、アプリケーションは断続的なタイムアウトを発生するように >なったのだ。 >しかしこの問題はすぐに解明され、リテールのアプリケーションが原因で >不用意に残ってしまったセーブポイントを削除するだけで完全に解決された。

>どうやらCNBCの記者は記事をOracleとAWSが絡んだセンセーショナルなもの >にしたかったようです。

*Webパフォーマンス虎の巻 https://qiita.com/usagi-f/items/10f35969f08dd01fa635 >パフォーマンス向上に対する施策は大別すると以下の２通り > - 軽量化（単純にやりとりするデータ容量を小さくすること） > - 圧縮 > - 削除 > - 最適化（その時に最も適している実装・実行をとること） > - 経路・順番の変更 > - 非同期 > >もっとも遅くしている原因を探して、それを対策するのが原則。「対効��」 >が絶対的正義である。手段から入るのは愚策。まず先に原因を知ることが重要。

*「Firefox 63」公開　トラッキングの防止機能追加、危険度最高を含む15件の脆弱性に対処 http://www.itmedia.co.jp/enterprise/articles/1810/24/news071.html

*世界一プレイされているゲームではチーターは隔離され同士打ちすることになる https://gigazine.net/news/20181025-catch-cheater-by-bots-fight/ >Riot Gamesによると、不正行為には大まかに「スクリプティング」 >「ブースティング」「ボッティング」の3種類が存在します。スク >リプティングは、非公式の不正なツールを使用することでゲームの >勝率をあげる不正行為。ブースティングはスキルの高いプレイヤーが >対価を受け取ってゲームプレイを代行するという不正行為です。 >そしてボッティングは、「ボット」と呼ばれるプログラムでキャラ >クターを自動で操作して経験値を稼ぐというもの。

>Riot Gamesによると、ボットと人間を機械学習によって見極める「全自 >動食器洗い機のようなシステム」を導入しているとのこと。つまり、 >ボッティングを行っているアカウントはボット同士としかバトルでき >ないように隔離されてしまうというわけです。

*「中国のスパイチップによるサイバー攻撃疑惑」記事がなぜ間違いなのかをサーバー専門家が解説 https://gigazine.net/news/20181025-investigating-bloomberg-supermicro-story/ >ケネディ氏は「たとえ専門的な知識がない人でもBMCがどのようにネット >ワーク化されているかを考えると、上記記述の誤りは明らかだとわかる」 >と述べています。運用するサーバー数が少ない組織でも、一般的にBMC >ネットワークは分離して切り離されているとのこと。

>そして、スパイチップ記事ではチップの正確性に関する議論が多数あるの >に対して、実際のチップの写真が出てきていないという点をケネディ氏は >不審に感じています。スマートフォンカメラを含めて、ありとあらゆる >場所にカメラがあるこの時代に、17人いるとされる情報源の誰もその >チップ実物の写真を収めていないというのは変だとケネディ氏は考えて >います。

>そして、仮にCPU-メモリ間に割って入る性能を持ち、コードを保持でき、 >ネットワーク機能を備えた「小さなチップ」があったとして、「いったい >どうやって製造したのか？」という疑問が残るとのこと。

*「Apache HTTP Server v2.4.37」リリース、TLS 1.3をサポート https://mag.osdn.jp/18/10/24/170000 >なお、TLS 1.3は1.2と比較して振る舞いが異なるため、クライアントや >設定の変更が必要になるという。

*EFSのパフォーマンスモードと、スループットモードについて https://dev.classmethod.jp/cloud/aws/efs-performance-throughput/ >パフォーマンスモードには追加コストがかからないため、選択する��フォー >マンスモードによるコストへの影響はありません。どちらを利用するかは >システムの要件次第になると思いますが、大規模なアクセス等が見込まれ >なければ、汎用モードの利用が推奨されています。

>PercentIOLimitメトリクスは汎用モードでのみ提供されるメトリクスで、 >このメトリクスが100%、またはそれに近い場合は汎用モードも限界に達し >ている判断できます。この値が頻繁に100%に達している場合は、最大I/O >パフォーマンスモードの利用を検討する必要があります。

>EFSでは後からパフィーマンスモードを変更する事ができませんので、 >モードの変更を行う場合は、新たに最大IOモードのファイルシステムを >作成して、File Sync等を利用してデータの移行が必要になります。

>バーストモードでは、使用しているファイルシステムの容量に応じてス >ループットが拡張されるモードです。

>なお、使用容量に関係なく、すべてのファイルシステムは、100MiB/秒の >スループットまでバーストすることが可能です。

>プロビジョニングモードでは、一貫したスループットが提供されます。

>プロビジョニングモードは追加料金が発生しますのでご注意ください。

>バースト状態BurstCreditBalanceメトリクスで確認することができます。

*EFSマウントヘルパーの利用有無でマウントコマンドの違い等をみてみた https://dev.classmethod.jp/cloud/aws/efs-mount-helper/ >マウントヘルパーの利用にはamazon-efs-utilsパッケージが必要になり >ます。

>マウントヘルパーの利用したEFSのマウントでは、 EFSのファイル >システムIDが必要になりますので、コンソールよりIDを確認します。

>マウントヘルパーを利用時は、推奨されるマウントオプションが自動で >実施されています。そのため、オプションの指定はありません。

>なお、EFSへのデータ転送時に、データを暗号化する場合、次のコマンド >を使用してファイルシステムをマウントする必要があります。

>マウントヘルパーには、EFSのログ記録が組み込まれています。